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ABSTRACT 


The objective of this thesis is to determine if a 
mainframe computer Automated Information System (AIS) can be 
simulated on a conventional microcomputer. To this end, the 
topical areas of software, hardware, the simulation 
development lifecycle, and systems testing and evaluation 
are explored in-depth. The purpose of this in-depth subject 
area examination is to demonstrate the tradeoffs and 
decision points encountered in the systems management 
lifecycle. Recommendations based upon these tradeoffs and 
decisions are then presented. actly, elem conc lusions 


address the attainment of the thesis objective. 
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In any decision making environment, a manager has three 
Peeteery Variables: manpower, money and information. 
Manpower, while still fundamental to any decision, enjoyed 
it's major emphasis in decision Tato r= 1 Or eo tthe 
Midtcet rial revolution. With the onset of the industrial 
revolution, money became the dominant decision variable. As 
Memmovestoward the Zist century, it is becoming obvious to 
many that manpower and money are becoming subordinate to 
MmMommatthonm in the decision maker's environment. {Ref 1 : 
Doe ie— 38 | 

The emergence of information as the dominant decision 
Paemapests the result of several trends. The first trend 
is the fact that information permeates both money and 
manpower, Semen Eemds to encapsulate the salient 
characteristics of both. Secondly, the increasing speed of 
Mminommation f£low has tended to cause it to be the 
Peecomuearing factor in many decision situations. This 
meeoremeton flow intensification has largely been the 
byproduct of computer and communications technology, coupled 
Meeeeeesopomenmtial growth in media forms. Finally, the 
organizational environment has undergone an ‘information 
Sxapeoston’ . fmcw exp boston mss tme result of the 


aforementioned speed increase of information, and an 





unprecedented growth in the absolute quantity of information 
oi maomrane Cecision makers. jRef 1 : pp. 189 - 2053 

Recognizing the dominance of information to decision 
HMepeeGoye lt iS tEhe intent of this work to concurrently 
examine and combine three vital information subsets: 
automated information systems, microcomputers and 
ameratiiom., to tackle this triad, a seven step/chapter 
format will be employed. 

Pmewesin this process, background information on 
automated information systems, microcomputers and simulation 
Will be presented. This will provide readers with a common 
knowledge base on these three topics. 

Following will be the problem definition. Included in 
this chapter will be the relevant research questions, and a 
descriptive ExXpianation of the initial decisions 
surrounding this thesis. 

Next, a decision model for microcomputer simulation 
software will be introduced. This decision model will 
reflect the software requirements and specifications of this 
thesis, and is designed to serve as an objective decision 
featieroutEne authors. 

Complimenting the software decision model will be a 
chapter on microcomputer hardware. Topics covered in this 
chapter include the selection process, the acquisition 
procedures and the maintenance aspects of the hardware 


Wevaces. 





iene xt Cihapter will cover the development of a 
Simulated automated information system on a microcomputer. 
Relying on the previous software and hardware decisions, the 
Menpmeemwis tne focal theme of this thesis. Critical to this 
development process is the simulation lifecycle, which 
SBenves a Structural framework for the process and a decision 
aid for the development team. 

~meeeivsctmOof the Simttlation lifecycle, the test and 
evaluation phase, is the subject of a separate chapter. 
Testing and evaluation is given separate emphasis, as it 
represents the critical link between the requirements and 
specifications and the delivered product. (eS Onp diac 
comprises unit testing, systems testing and the user 
feedback loop. 

The last chapter serves to summarize the entire work 
through recommendations and conclusions. Recommendations 
address possible future directions of this thesis. The 
Somemiciwons will provide answers to the previously 
introduced research questions. 

Explicitly, this thesis deals with numerous, intertwined 
technical topics. Underlying these surface areas are the 
fundamental topics of communication and decision tradeoffs. 
Throughout this work, every effort will be made to jointly 
couple these fundamental subject areas with the technical 


themes. This deliberate emphasis is intended to illustrate 





the multi-dimensional environment in which this thesis was 


developed and exists. 
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IT. BACKGROUND 


Mame Ukr Oo E 

In order to evaluate the researchable GleSstions, 1 is 
necessary to describe and analyze the three major subsets of 
this thesis: Automated Information Systems, Microcomputers, 
and Simulation. This chapter will develop a historical and 


academic perspective of these three topics. 


B. AUTOMATED INFORMATION SYSTEMS 

A Manager confronts his crowded desk. The face of his 
desk is layered with memorandums, correspondence and 
We DOr tS « Among the reports are several printouts from the 
data processing center. These particular reports, printed 
entirely in upper case by a line printer, are the byproducts 
Semamenitomated Information System (AIS). The term 
Automated Information System describes the information 
resource manager in most organizations. 

Atoms typically is ablle to accumulate data from 
multiple locations. Collection mechanisms include data 
iemeeeaee cathode ray tube (CRT) terminals by human 
Opematers, Htollerith cards, magnetic tapes, bar code 
readers, remote job entry, and many types of mechanical and 
electronic sensing devices. Once the raw data has been 
routed into an AIS channel, it normally undergoes a series 


Cimpcad rece to Validate and verify the content. The AIS 


ik 





editing process is intended to prevent the ‘Garbage In, 
Garbage Out cycle of information processing. Upon edit 
eee meempletion, valid data enters into the processing 
€yele. The purpose of the processing cycle is to aggregate 
PaeemeOn an organizational resource for decisions: 
mirormation.. 

The preceding description emphasizes the information 
development and production phases of an AIS. In addition, 
an AIS normally serves as an organization's information 
Storage medium. As with data collection, a diverse mixture 
of storage devices are employed e.g. disk packs, magnetic 
Meaeemmmar dad cCcOpyY printout and microfiche. Prevalent 
throughout both the production and storage functions of an 
AIS are the security features. These features limit access 
to information upon organizationally defined criteria. 
Meera yeot an ALS is a dynamic and sensitive area, as the 
AIS frequently contains undisclosed elements of corporate 
Beis eee y . 

Mieacdi1tlen tO producing and testing information, an AIS 
communicates with the organization. This communication is 
accomplished through the channeling of information to 
different organizational echelons. Although no universal 
Sum@uemmsire OF  LOrmat tor this channeling exists, it can 
generally be categorized as follows: 

1. Scheduled Reports: Normally produced in hard copy 
Mambcut on a recurring basis. Primarily employed by 


operational/tactical level managers as a barometer of 
day-to-day operations and performance. 


ie 





2. Unscheduled Reports: Normally produced in hard 
COpy printout only when an exception condition occurs. 
Primarily used by middle/control level managers 2s 
indicators of potential or existing problem areas. 


3. Inquiry Responses: Normally produced in a real time 
Sieveepwomuent Via soft copy on a CRT. Used by 
upper/strategic level managers as a source of 
Pihomma ton bomanawim decisionmaking and/or in 


planning. 

The presentation of these categories strongly indicate that 
MomOlEpimt Of an ALS is intended to directly affect 
managerial decision making. Herein lies the objective of 
any AIS: To provide timely, accurate and understandable 
information to users designed to foster the accomplishment 
of organizational objectives and goals. 

ome Goes Not exist in a vacuun, Rather, it 
interfaces with several different environments. The two 
primary AIS interfaces are with the hardware/software 
PaPeermomniment in which the AIS dwells, and the larger 
Organizational environment which the AIS supports. 

ieephyscieal terms, an ALS is merely a complex and 
integrated coupling of hardware and software components. 
This coupling causes the AIS to be perceived as a 
transparent mechanism to the external organization, except 
to the data processing department. Routinely, the hardware 
foundation of an AIS is a large, general purpose mainframe 
Sompuwiter. This hardware foundation reflects the early 
SGeemmenmor centralized data processing in many concerns. 
Additionally, it indicates an organization's desire to 


Smet eremmeiinc access and distribution of information. 
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Examples of such general purpose mainframe computers are the 
Mptreo@mx Series, and the Amdahl 470/VX series. 

The dynamics of technology have caused the hardwar 
arena to expand outward in several directions. The first 
Meeeaed step involved the hard wiring of terminals to a 
central mainframe computer. The appearance of such 
Peummmemates, like the IBM 327X series and the Telex 278-2, 
Bembeeee ene Erend toward interactive data entry and inquiry 
Pee eoteauenls. “The logical successors to 'dumb' terminals 
eeemeousthese are the current generation of ‘smart’ 
terminals. Possessing all the capabilities of dumb 
terminals, a smart terminal also is capable of editing and 
performing some preprocessing of data prior to transmission 
fO.a central mainframe processor. .The smart terminal 
positions a significant amount of computing power directly 
at the user level, while simultaneously reducing the 
processing workload of the mainframe. The best illustration 
of a smart terminal is the field salesman with his 
Microcomputer and modem. He can input and prepare his 
reports on his microcomputer at a decentralized location, 
and then transmit his preprocessed data to the central 
information manager via normal telephone links. 

An alternative architecture to the smart terminal 
approach is to use dumb terminals coupled to a front-end 
processor. The front-end processor is normally a mini- 


Gometer, which is dedicated to editing and limited 
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Peoeesoime functions before transmitting data packages to 
mmemcentral information manager. ime DEC PDP-1ll is 
frequently used as a front-end processor. This approach to 
the hardware side of an AIS is particularly well suited when 
@ate is transmitted from multiple locations, the data is 
edit intensive, or authority/responsibility is decentralized 
to the regional organizational levels. 

several AIS hardware alternatives are currently 
developing on the leading edge of technology. Heightened 
interest and intensive research is revolving around the 
database machine. The database machine is a back end 
Meoeessor ; it logically lives behind the central 
information manager. iwc eentnectionaldy and physically 
dedicated to database operations. Such devices are 
architecturally tailored to the unique aspects of database 
operations, e.g. specially designed memory registers, and 
the application of expandable buffers. It is likely that 
the database machine will gain a strong following in the AIS 
world, as they represent an economical and more secure 
answer to the shrinking availability of mainframe processing 
resources. 

Another area of interest involves distributed AIS 
systems. Conceptually, such a system will allow the 
Zwiemrruovofean AIS, both in logical and physical terms, 
omelet ly correspond to the organizational 


responsibility/authority levels. Currently, the distributed 
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Seem euced internally by Hewlett Packard in support of 
sales, manufacturing and distribution operations represents 


‘ A ol Gs + ee , lan - oe - —— fess ~~ 2-8 -™& Nes Foe 
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a success 
ememimpeted ATS are stronger intra-organizational 
mieomimataton flow; and enhanced real time information. 
Organizations have been fairly reluctant to venture into the 
Pegenioited AlS arena, This reluctance is a function of 
a vemaieieroniy publicized distributed AIS failures, e.g. 
IBM's failure to develop a distributed reservation and 
HoworEmme system for the Holiday Inn Corporation in the 
Soh cee the lack of concrete €orporate information 
emadeeimyecand am inherent organizational tendency to 
centralized information processing functions has also slowed 
corporate entry into the distributed arena. 

Complimenting the hardware functions of an AIS are 
powerful software systems. The basic AIS software package 
Meonamarly incorporates the following functions: 


Matisse ta1on Processing: Tie sin pte ed stan and 
appending of transactions to files and/or databases. 


Geet rte/ Database Management: A fave sored ata base 
PepcryGuem. Structured in hierarehical , network or 
Remar onal architecture. 

eeoekemort Generator: An Output oriented function, 
designed to assemble information from multiple sources 
into user-readable formats. 

The above features are normally layered several tiers above 
the operating system in the virtual machine. Dependent upon 


the respective AIS source language, the operating system can 


serve varied functions. In a COBOL-based AIS, the operating 


dk 





Seeded y serveWas the supporting file manager. 
Increasingly, many AIS's are being created with modern, 
powerful, pseudo-procedural packages known as fourth 
generation Ilnaguages. Information Builder's FOCUS and 
Mathematica’s RAMIS II are current examples of DBMS- 
Oriented, fourth generation languages. These fourth 
generation languages may ignore the host operating system 
and establish its own physical interface with the hardware. 
They are also fully capable of being piggybacked on top of 
Many existing operating systems and database management 
systems. Regardless of the circumstances, the presence of 
Phe operating system is normally transparent to the AIS 
user. 

hMieeralhy, COBOL was a nearly universal choice for the 
AIS source language. The extensive use of COBOL reflected 
the government's heavy sponsoring and backing of the 
language, and the semi-structured nature of the language. 
As the complexity and use of AIS's grew, COBOL has become 
less common as a source language. This decline in the use 
of COBOL in new systems comes from COBOL's orientation to 
Weremeeprocessime, it's lack of organic statistical 
capability and the appearance of integrated database 
Management packages. However, COBOL is by no means a bygone 
memory. To the contrary, the multi-million line COBOL-based 
AIS's present throughout the public and private sector will 


ensure the existence of COBOL well into the next century. 
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AS previously described, hardware technology has been 
changing at an unprecedented rate. Lagging behind the 
Maeeane Lrevolution has been the software evolution. 
Relative to the AIS world, the software evolution is perhaps 
best illustrated by the proliferation of database management 
systems (DBMS). Peet cerceletrr onal database SHOUEL; and 
software AG's network database ADABAS are two currently 
successful commercial examples. The integration of a DBMS 
merece, an AIS frequently serves to extend the useful life of 
AieoeenAIso, it permits the evolution or expansion of an 
AIS from the batch processing environment to the interactive 
processing environment. Lastly, it produces mixed results 
by broadening the base of an organization's AIS users. 

Outside the btn areyeoteware environment that an AIS 
exists in is the broader organizational environment. It is 
fie this environment that an AIS has several areas of 
Significant concern. First, the AIS is usually the primary 
responsibility and source of corporate identity for the data 
Processing department. This routinely generates 
Om@anmmezat@onal conflict, especially with the growth eye 
interactive processing. Secondly, an AIS normally parallels 
the reporting and performance evaluation hierarchy within an 
Organization. If improperly used, subordinates can fall 
into a numbers game to satisfy the AIS scoreboard and lose 
sight of the underlying organizational objectives and goals. 


Also, the AIS can develop into the primary communication 
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link within an organization. Generally, this is improper as 
the AIS is intended to enhance decision making and rot 
circumvent human communication. The prevalence of AiS’s in 
organizations has nurtured the development of ‘management 
by exception’ leadership styles in certain managerial 
circles. While such leadership styles have a definite time 
and place in any time-parametered organization, it's value 
as a blanket replacement for the more traditional leadership 
styles is debatable. The implementation of an AIS within an 
organization normally produces an avalanche of information 
at the decision maker level. While permitting more informed 
decisions, an AIS can also serve to cloud a manager's 
perspective with mountains of trivia. Lastly, AIS's have 
significantly increased the speed of information flow within 
organizations. Given reliable computer resources, much of 
Sreomemmelag and information ‘float’ present in previous 
Manual systems has vanished. In the face of computer 
Peseuree ftaillre, information can be inaccurate, unavailable 
or simply vanish. 

As is evident by the preceding paragraphs, an AIS is a 
complex mechanism with significant and far reaching 
Organizational effect. A classic real world example of a 
dynamic and evolving AIS is the Joint Uniform Military Pay 
System (JUMPS), the uniformed services compensation system 
employed by DOD. Another public sector AIS is the Supported 


Activity Supply System (SASSY), the supply system employed 
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Mepetemoperating forces of the U. S. Marine Corps. In the 
private sector, the centralized corporate management 
reporting and information system employed by Texas 
Instruments is an example of a successful corporate Als. 
Like any evolving technology, AIS's are a two-edged 
sword. Many pitfalls surround the implementation and use of 
fewer erhaps the bisgest drawback is that any AIS is 
mecieeyvessusceptible to Parkinson's Law. (ima ta lis Bene 


workload and information requirements of an AIS will tend to 
expand to equal the available resources. Liem ie Pens ule aod 
this effect is a scarcity of mainframe processing resources. 
A public sector example of this phenomenon is the JU. §&. 
Marine Corps. Having recently purchased seven (7) Amdahl 
470/V7 mainframe processors, the Marine Corps felt that it's 
processing requirements would be satisfied until the mid- 
1990's. This proved otherwise, as this organization is 
currently experiencing a 92-95% CPU utilization rate [Ref. 
aap v— | |. 

A second fundamental AIS problem deals with the primary 
output of an AIS: information. Information can lack value, 
lack timeliness, lack validity and experience quality and 
quantity weaknesses. The lack of timeliness may be a 
function of system output scheduling, age of data and 
timelag of input or more simply, the steadfast requirement 
to have real-time information in certain decision making 


situations. The timeliness obstacle is diminishing with the 
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growth of interactive processing. Validity problems can be 
driven by a myriad of problems ranging from system logic 
Meereeeer rors to intentionally erroneotis data input. 
metwemveran Abo 1S a Vast reservoir of information. The 
output of this reservoir can flood the user with data. The 
Beetemois this data, both from a quality and quantity 
perspective, in actual decision making and problem solving 
PmomOrmen suspect. Direc meclahit dq anhtit vy. ep oo bem as 
primarily present at the operational levels of management. 

The other primary problem of an AIS revolves around the 
System development. In the system development arena, the 
problems stem from interfaces, conversion of systems and the 
training/documentation/maintenance phase of the AIS 
lifecycle. 

Interface problems develop both at the user level, and 
with the existing and external systems. User level 
interface faults surface around the organizational interface 
with users, definition of user requirements, and user 
communication channels. Interfacing with existing and 
Seeaertial systems causes data CAOunN pases Dea iE y 
telecommunications and hardware compatibility questions to 
be raised. 

The most exasperating and time intensive system 
development dillema relates to the conversion of existing 
So Seetiow es Broad problem spectrum, including data structure 
eomsadenations, source code transformation, and DBMS 


Piugsmeats structure decisions, must be addressed when 
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Souwewraees an AIS. The best tools to have when dealing with 
conversion problems are an experienced and open minded AIS 
manager, and established corporate information policy. The 
remaining basic system development dilemma involves the 
ongoing training/documentation/maintenance phase of the AIS 
irecyele. 

Training frequently spells the difference between 
meeecesseand failure of an AIS in an organization. The 
Wieieree perrormance bartwmeter is user satisfaction. 
Mocumemtation is an expensive ongoing and iterative process 
that can be significantly reduced by effective management. 
Complete and accurate documentation is essential, as it is 
the historical and permanent guide to AIS development. This 
Memerwereal in the AIS arena, as personnel turnover is 
Pitemtemy rapid. AIS can produce synergistic difficulties. 
The way to avoid these difficulties is well planned 
Maintenance in response to user requirements and resource 
availability constraints, coupled with a clearly defined 


SQmperare anfoOrmation policy. 


C. THE MICROCOMPUTER 

Hiom@emerecentiy, a new character has crept into the 
spectrum of managerial decision making. Hailing from a 
Pomemommot California known as the ‘Silicon Valley’, this 
new decision partner is the microcomputer. With curious 
nMames like the Apple II and Heathkit, managers initially 


rebuffed the microcomputer as a hobbyist's toy. The cottage 
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microcomputer industry listened to the message, as their 


product offerings underwent an exponential propagation in 
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reliability. The best example of such a ‘refined’ product 
offering was the Apple II+ microcomputer coupled with the 
VISICALC electronic spreadsheet. This point of departure, 
mimsivememate 19/9" —- early 1980 timeframe, marked the 
migration of the microcomputer from the hobbyist's workbench 
to the manager's desktop. Later events, ranging from IBM's 
introduction of their Personal Computer in September, 1982 
to the development of integrated management software tools 
like Lotus 1-2-3 and Context MBA, have firmly established 
Lic esl caocomiputer as a managerial decision aid. The 
microcomputer entry into the management limelight, coupled 
with their relatively low cost, has led to a proliferation 
CummrcrOcomputers in many organizations. 

Weiewbnds ss anoOrdinate amount of interest generated 
towards microcomputers, it becomes necessary to examine the 
> W's and the How of the microcomputer. Simply stated, a 
Mrcrocomputer is an electronic device that peeepits data, 
Manipulates it to solve problems amd produces an 
Cranmer? onal resource: information [Ref. 3: p. 40]. 
iits electronic device, like any computer, is composed of 
six interrelated components: 

1. The Input Device: A mechanism that allows the 
Damctocrmmation of raw data into a format 


understandable by the computer. ies Croc OM pucker 
Systems, the standard input device is a keyboard 
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coupled with a video monitor/cathode ray tube (CRT). 
This allows the operator to see and verify the input. 


mitemeremory: The internal data warehouse cof the 
computer. Ped lOwecesrcnaom access of date. and is 


normally cailed RAM (random access memory). RAM 
capability is measured in kilobytes (KB). A kilobyte 
equates to the storage of 1000 arabic characters. At 


a minimum, a business oriented microcomputer system 
should possess 64 KB of RAM, with 128 KB or greater 
preferred. 


Secondary Storage: The external data warehouse of the 
computer. Depending on the microcomputer system, 
secondary storage devices can be floppy diskettes, 
magnetic hard disks or cassette tapes. Access to data 
Pecgebatavely longer than RAM, but more rapid than 
comparable manual means. The capability of secondary 
ei@mae as also measured in KB's, This capability 
varies tremendously. As such, no universal ‘rule of 
thumb’ exists for secondary storage capacity. Rather, 
secondary storage capacity should be directly 
reflective of the needs of the respective application. 


Maeomeentrak Processimg Unit (CPU): This is the 
meer iat Drain of the computer. The CPU thinks 
Panay simemmmeric terms, and its ability to think as 
such provides performance measures. Often, a CPU is 


Spricen "Ot in terms of ‘clock speed’, which is stated 
in megahertz (MHZ). In plain language, clock speed is 
the rate at which the CPU thinks and operates. A 
faster clock will produce quicker results than a 
sewer clock, all other things equal. Microcomputer 


clock speeds range from 1.5 MHZ to greater than 10 
MHZ. CPU's are also measured in terms of ‘word 
Serer Word size is the number of binary characters 
Gets) used by the CPU to communicate within itself 
and with other parts of the computer. A bigger word 
Seyemeuall serve tomincrease the speed at which 
arithmetic and logical operations are performed, and 
Praduces i#mermeased numeric accuracy than a smaller 


Me@m@eesize, lypical word sizes for microcomputers are 
ceeeoowand 32 bits. 


The Output Device: This is the medium used to present 
information from the computer to the user. Output 
ieeececemare normally either CRI's and/or printers. 
CRT's are measured in terms of screen resolution, and 
pemeenmem ze. Generally, a 9 inch diagonal CRT with 
160 by 100 pixel resolution is the minimum to be 
pocudeged Lor a Microcomputer system. Also, CRI's 
Boemavarlabile in numerous screen colors. Amber is 
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thought to be the most favorable color for human 
users, with green phosphorus also being used widely. 
Multi-color screens, known as RGB for their use of the 


primary colors red, green and blue to produce the full 
Maer aum OL colors and hues, ere available and 
frequently used in training environments. Likewise, 
Pere as Can be thought of in two ways: py inet 


readability, either letter quality or dot matrix, and 
Speed, in characters printed per second. The printer 
to be used is a device tradeoff between the desired 
muecdeeoi print and the application.e.¢g. word 
Deoeecessing, forms, graphics. 

6. The Software: This is the real power of any computer. 
Memeives the CPU common sense and applicability from a 
user's perspective. Additionally, it serves as the 
interface layer between the bare electronic machine 
and the user's keystrokes on the keyboard. It comes 
in a multitude of varieties and flavors, and can be 
considered to be somewhat specialized. Owing to this 
Specialization, the software should be the first and 
Demem@ary component selected in any microcomputer 
system. 

These six components, when bundled into a coordinated 


package, possess the ability toremmance productivaty an 
a many decision environments. The critical caveat to any 
package is that a clearcut requirement/specification should 
drive the package configuration, rather than the package 
Somenration being the result or reflection of cleverly 
projected advertising campaigns. 

pommemerec ht be anticipated, microcomputers have 
Pecieeemeamily aifected organizations. The direction and 
magnitude of the microcomputer ripple effect is permeating 
mihoedieieeiievels of organizations, ranging from sole 
Poeoprisatorships to the boardrooms of the Fortune 500. 
Perhaps the foremost microcomputer impact has been the 


tendency to decentralize organizational power and knowledge 
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bases. Whereas a middle level manager would have had a 
staff analyst to aggregate and interpret information, now a 
subordinate manager can perform the same tasks with a 
Microcomputer. Many organizations have done some real soul 
searching to deal with this sudden and unplanned migration 
Pr oruatton. A related spinoff to this migration has 
been the reduction in staff analysts in many organizations 
weoeteee, pe oc |]. “Microcomputers are being economically 
substituted for these staff analysts, creating a leaner 
organization and a cadre of unemployed staff analysts. 
Another affect of microcomputers in many organizations has 
been the demystification of much of the aura and black magic 
peevuousiy engulfing computers. Simultaneous with this 
femrstitication has been the dilemma of weakened 
Pereeronaiaty and vanishing corporate identity for data 
processing (DP) departments. What had formerly been the 
exclusive domain of DP personnel has now ballooned to 
include any manager with a microcomputer and modem. 
Peelememeedaiy, this situation has generated intra- 
Organizational conflict. No simple solution to resolve this 
Srientert Mas proven optimal. However, the presence of 
Somere renorganizational information policy has tended to 
Wemeteeeze thas type of conflict [Ref. 5: pg.42]. A more 
predictable result of microcomputers in organizations has 
been the development of data redundancy, appearance of many 


data security problems and the emergence of an entire 
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spectrum of compatibility considerations. Data redundancy 
has been reduced by the appearance of multi-user, shared 
herd disks, DeGleertry, “tewever. is a millti-dimemsional 
/P_ioweweewrtm no absolute solution on the horizon. The 
Sweparibiiity question is resolvable with solid, defined 
corporate information policies and procedures. 

Another effect of microcomputers has been the tendency 
of some users to divert energies away from their assigned 
tasks due to a compulsive interest in the computer. This 
compulsion goes beyond learning the applications programs of 
the microcomputer, and can effectively turn a manager into a 
assembly language programmer. This is a serious negative 
Pesuimeand wean result in non productive expenditure of time 
mime cotnees. The best solution to this dilemma is the 
traditional role of the manager as a supervisor of his 
Subomdimates, to insure that a subordinate is investing 
adequate resources into his primary responsibilities and not 
es olveneeato a microcomputer addict. 

Maetiy, the entry of microcomputers into an ompganization 
often creates a new status symbol and power emblem. This is 
a potentially dangerous situation, as it represents a source 
Pinta organizational conflict and a possible resource 
Gmapemaicture for pure status purposes, not productivity. 

The description of microcomputers in organizations 
described herein creates a Pandora's box perception. 


Despite this portrayal, microcomputers have had a positive 


27 





and advantageous effect on many organizations. Perhaps the 
most visible and relevant effect has been the enhanced 


Pemelivaty and additional time availability entoved dy 


decision makers. The mere presence of an automated ‘What 
If' capability is much more time efficient and accurate than 
the time honored stubby pencil and ledger pad. The combined 
PMipiGewor productivity and time availability is particularly 
germane when dealing with crisis management situations, the 
plague of operational and control level managers. An 
example of practical use of this ‘What If" capability 
involves the recalculation of pre-exercise cost estimates in 
Brewer soe Marine Corps. These estimates, which are usually 
driven by several key variables like type and quantity of 
Penemwnrerlteht hoyrs, tank operating hours, amphibian 
assault vehicle operating hours and battalion field training 
days, can readily be modeled using an electronic 
Spreadsheet. To recalculate the total cost estimate using 
such an electronic spreadsheet involves the simple changing 
of several total resource inputs, with the reminder of the 
calculation being done by the microcomputer. This procedure 
would take an intermediate computer user several minutes. 
Manual recalculation of the same exercise cost estimate is 
usually a several hour, if not several day, process, and is 
Suiiectmto a Great variety of errors. 

The presence of microcomputers has also created the 


iemomencn known as ‘silent firing’. [Ref. 6: pg. 28] 
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melemte tiring involves the application and exploitation of a 
microcomputer pon handle an increasing workload, vice 
Miigemeame Fine personnel staff. This can be an extremely; 
meIsouree ©fricient usage, especially in the face of rising 
personnel costs. 

Microcomputers have also allowed users to get multiple 
and diverse perspectives of the same information. io 
illustrate such a situation, a DBMS will permit numerous 
views of a consumer demographics database. These various 
views can often unlock the secret to penetrating a 
designated target market, or enhancing the promotional 
effectiveness within a given Standard Metropolitan 
meager teal Area (SMSA). 

The microcomputer graphics revolution has bolstered 
Mmera-ormeanizational communications. To wit, the desire to 
Havewetaphics capability by activity level comptrollers in 
the U. S. Marine Corps is an instance of such communication 
meee 7: pe. 30]. 

Finally, when properly implemented, microcomputers can 
be a significant morale booster within an organization. 
Organizational members frequently feel they are part of the 
‘high tech metamorphosis’ that seems to be enveloping 
society. Being a part of what is perceived as a progressive 
and affirmative movement normally has a beneficial effect on 


group members. 
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De seu DAT TON 


To simulate generally denotes performing actions that 


Le ss — (a = e _ I 2 . = ‘ peas aes 
Mu~emeemeesesehipla reality. With resard to decision mrkinrga, 


mer 


Simulation normally means the use of a support environment 
Ewowmcomouters, visual aids to interact with and exercise a 
model of a parent system. With simulation, the nature of 
the outcomes is not preordained upon interaction. Rather, a 
meeerepectrum ot resultant conditions is possible. To 
Pear tze these descriptions, simulation can De 
Pomeepttalized as an interactive participant's tool box. 
The tool box contains multiple models and a legion of 
conceivable consequences. 

Shannon defines simulation as the process of designing a 
model of a real world system and conducting experiments with 
the model [Ref. 8: pg. 2]. The purpose of these experiments 
is to gain an understanding of the system and its related 
behavior, and to analyze various strategies (within known 
en@eartif£icial constraints) for the operation of the parent 
system. 

Peepeece the generality of this definition, it is 
possable to identify several intrinsic characteristics of 
Simulation. Foremost is the trait that simulation is driven 
by models. Seeonds, Simulation 1s a ~detscriptive, not a 
normative, management device. Lastly, simulation is used 
when the parent system is too obtrusive to be encapsulated 


by routine analytical and optimization methods. 
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The relationship between simulation and models is 
essential. Models serve as the building blocks to represent 
Maempe@eltec! reality. By constructively organizing these 
Mmemecems Diocks, a simulation is created. The use of the 
building block concept permits modular development of 
Semibations, and favors graphical representation of 
Simulations. A well conceived model attempts to incorporate 
only the relevant and accurate aspects of reality, and 
desires to avoid irrelevant aspects. This modeling feature 
tends to decrease the complexity of simulations, increases 
their resource efficiency and simplifies user understanding 
of the simulation. 

Pyaepeamo a descriptive device, a simulation does not 
necessarily search for the optimal outcomesin a_ given 
See wat on . Rather, it merely portrays the characteristics 
of the subject system under varying conditions. This 
trait implies a requirement for user interaction and choice 
Momesetlectsa decision path. <A flight simulator, which is 
Gomoacanmtly requiring user responses to Situations, 
exemplifies this feature. 

Simulations are employed when routine management tools, 
such as linear programming and the transportation method, 
cannot capture the essential features of a situation. This 
simulation use reflects the lack of programmable optimality 
im the parent system. Also, it might imply that the 


formulation of an optimal solution is possible, but not 
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resource efficient. The nature of many simulation problems 
erreOreo tnhteracting and dynamic variables that cannot be 
eeedee- yy estimated by probability. To wit, consider the 
case of a large, multi-user mainframe computer center. The 
computer center is faced with irregular batch processing 
requirements, fluctuating interactive processing demands 
Mervenm, bY terminal reliability and user workloads, 
Pefetromic Component mean time to failure distributions, 
fittbeeeety in external power supply and turnover in 
mercennel staff. Quite simply, a simulation is better 
Suited of representing this myriad of variable components 
than an analytical or optimization methodology. 

(ewenm simulation traces its origins to Edwin Link. 
Link sold his first foul-weather flight Simulator to the 
U. S. Army Air Corps in 1933. Combining some boxes, a few 
mopeuments and a stick, this flight simulator employed a 
primitive motion system. World War II saw a proliferation 
of Link's basic ideas, as countless pilots trained on Link's 
mie boxes', Technology has significantly boosted 
simulation, as modern simulation devices can realistically 
PeGeeray tlight in a commercial jumbo jet and the space 
Siuik st Le. Slicer tLechmo logy, al SOULS TrOWwEn Ofte computers, 
sensual enhancement devices and environmental control 
systems, has effectively relocated reality into an 


m@eiacmal setting. [Ref. 9: pg. 159] 
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Froduct applications of simulation can be generically 
categorized into the following three areas: 
Meeeectcion Iraining simulation. 
2. Physical Response Oriented simulation. 
3. System Observation simulation. 
These categories are not mutually exclusive, but rather are 
meteoric elements that combined produce realism and 


Seearoility to the simulation user. 


Decision training simulations involve confronting the 
participant with a discrete quantity of alternatives that 
are intended to strengthen his judgement. This type of 
simulation is enjoying widespread application in both put Te 
and private sectors. The Standard Embarkation Management 
System (SEMS) simulator, a computer-based simulation device 
Geveloped by the U. S. Marine Corps for logistics training, 
is currently being used at Landing Force Training Command, 
wearateqe and Landing Force Training Command, Pacific. Users 
benefit from learning in a real-time environment, as well as 
from being exposed to computers. The organization benefits 
iieenaeethne teaching syllabus was reducible from four weeks 
to two weeks due to the simulation, and from the simulation 
being implementable on existing assets (an IBM Series Il 
minicomputer). DeBord and Siebel describe a similar 
Bimenesimulation and benefit accrual in an unnamed 


Private sector organization [Ref. 10: pg. 42]. 


oS 





Physicalresponse oriented simulations prompt decisions 
From participants, and evaluate the correctness of supplied 
responses. The nature of the responses serves to generate 
immediate changes to the external environment surrounding 
the simulation. These changes connote success or failure at 
a task, and range in magnitude from losing an arcade game to 
eimemetne simulated subject of a confirmed kill from an 
aggressor's air-to-air missile. A recreationally oriented 
physical response simulation is called the SR-2. Physically 
resembling a Volkswagen bus supported by three giant shock 
aesOnbers, this product of Doron Precision Systems projects 
an image of road racing, roller coaster rides and a combat 
fighter mission in Vietnam to twelve simultaneous riders in 
PeecuUreminute timespan. This simulation is complete with 
sound and wind effects. Realism and reality are stressed in 
pmemommeer Link Flight simulation at Williams Air Force 
Base, Phoenix, where fighter aircraft pilots leave tandem 
F=4 coekpits drenched in perspiration. William Turner, 
PeecniemerOor  sineer s Link Flight Simulation division, 
refers to such participant involvement as ‘the pucker 
mIGrorwmprer. 9: pg. 159]. 

System observation simulations revolve around the 
(maneemmand continuous interaction of parent system 
elements. The simulation's purpose is to produce snapshots 
of identifiable outcome subsets of the parent system. 


Normally, this type of simulation is employed where multiple 
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eomponemes interact in irregular manners. It can serve as 
an economical substitute for laboratory and reali world 
experiments. Currently, the Environmental Protection Agency 
feccmeemts type of simulation to project the effect of 
PortlutamtsS on air basins. Fortune 300 firms tuse system 
observation simulations to forecast economic trends and 
paoawet Litecycles. tioSeatype Of forecast cannot be 
commonly solved using traditional analytical and regression 
mechanisms. 

Pia tion 1S having, and will continue to have, a 
definitive impact on organizations. This impact produces 
POrmepoamtive and negative byproducts. iinewousch care fud 
Peaonieenewns aide iansightful techniques, organizations can 
exploit these advantages of simulation and avoid the 
Petiralls. 

Poeommethe positive perspective, the benefits of 
simulation can be enumerated as follows: 

Pi relation “prevides participants the opportunity for 
repetitive use. In training environments, whether 
decision or physical response oriented, repetition 
tends to foster reinforcement of actions. enaes 
reinforcement tends to produce a more effective 
meeomrees when he/she retttirns to their actual 
SaeaiiZcae onal position. 

2. Simulation compresses time. This increases its 
efficiency as a training resource, as well as exposing 
Pamsticipants to conditions that might take several 
years to encounter in on-the-job conditions. 

7 esemlations allow users to experience disaster and 
Sieweccewithout harming the organization. This can 


Peete cs an intangible maturity factor in the 
Paes ci pant . Additionally, this feature is integral 
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By 


Peers Credibility of physical response oriented 
Senet ions . 


Simulation remain somewhat of a novelty item. As such, 
Pmey eenerally produce high levels of participant 
MUterest. Htecoowlceaquvitalelink to the successful 
implementation of a training program. 


A properly developed simulation causes developers and 
managers to gain a deep and comprehensive knowledge of 
the parent system. This knowledge base can foster 
better decisions concerning the controllable variables 
Tmrempaneit system, Also, it frequently generates 
enhanced intra-organizational communication. 


Simulation is a two-edged sword, as the negative aspects 


Pimoaiwce Significant organizational obstacles. These 


pitfalls include: 


Te 


Simulation creation and development is a time and 
resource intensive process. Although formal research 
SJewiot support it, it is reasonable to assume that 
SHmmiibation 1s a contributing factor to the ever-rising 
S@ramwane COSt Curves. Two possible options exist to 
meeemty this problem. With in-house developed 
Simulations, all reasonable attempts to retain and 
reuse this corporate knowledge should be applied. In 
that simulation development is often a personnel 


intensive task, this guideline implies personnel 
Fetention policies and incentives. If developed 
externally, serious consideration to sole source 


acquisition from the same vendor should be given. 
(Note: This assumes user satisfaction with the initial 
Simulation.) In either instance, the cost and time of 
reclimbing the learning curve are avoidable by this 
Sect e gy , 


emulation is an art, not a precise science. It is 
not an emulation of the parent system, and will not 
identically replicate all system behavior. The 
So mmtron to this problem lies in initial system 
definition. If the parent system can be reduced to a 
Samptlesmode! that is solvable with analytical oOo se 
Simulation should be avoided. This avoidance will 
prevent the development of an emulation, and the 
unneeded expenditure of resources. 


Simulation is frequently perceived by users as the 


Warversal solution to all their problems. This 
mindset is particularly pervasive in the training and 
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Muse nruction arenas. two. tactics are available to 
combat the unrestrained proliferation of simulations. 
eee Pron, £O entering into the develocnrent of 2 
major simulation, a FP eagdleee study and cost/benefit 
Pidemescts SHOuUlG be conducted. if the simulation is 
beyond the availabdl resources, or tails to meet 
Smeeatiezabtonal payback criteria, it should be 
abandoned. Secondly, The development of organization- 
wide simulation libraries and user groups can serve to 
prevent unnecessary duplication of effort within a 
Goreern . Hewlett Packard has been extremely 
Smeecesstiul with this tactic in the applications 
programs area, and the concept is readily transferable 
EOuresimulations. 
mamomaer to lend some structure and flow definition to 
the pseudo-science of simulation, the following Simulation 
Development Lifecycle was developed by the thesis authors. 
The origins of this simulation development lifecycle are: 


1. Boehm's Waterfall Model of the Software Lifecycle [Ref 
11: pg. 35 - 46]. 


2. The generally accepted principles of simulation and 
Gomdemwame [Ref. 8: p. 22]. 


3. Brooks's insights concerning Project Management [Ref. 
1 


The simulation development lifecycle is a hybrid mixture of 
these sources. 

The waterfall model of the software lifecycle was 
selected for use as modern simulations are increasingly 
dependent on computers. As earlier discussed, software is 
Bremiaecard force in the computer revolution. By default, 
software becomes the weak link in the simulation chain. 
Integration of the waterfall model of the software lifecycle 
into the simulation development lifecycle provides a proven 


model base for this understrength member of the simulation 


bead, 
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PiceapoGetwon cf the generally accepted principles of 
Simulation and modeling serves to uniquely identify this 
lifecycle model as pertaining to simulation. 

Paoety, the inclusion of Brooks' audeas reflects the 
fact tiat simulations are frequently the result of project 
Management organizations. fiewterd learned lessons of 
Brooks and the OS 360 operating system provide a wealth of 
practical management thought and consideration to this 
lifecycle. Summarizing Brook's management insights, the 
following critical themes are evident [Ref. 11]: 

Weemeaecreative activity with ‘tractable medium’, 
computer programming is more subject to optimism than 


Other engineering tasks. 


2. A large project can only sustain a 304 per year 
manpower buildup. 


3. If you cannot avoid rescheduling, take the necessary 
tmme to do a careful job. 


4. When reducing activities, explicitly trim the tasks. 


Peacomerete, measurable milestones are necessary in 
project management. 


6. Do not defer action on problems to specified review 
periods. Take action on problems when they surface, 
and distinctly separate status review from problem - 
fetmwon efforts. 

Ignoring this rich collection of real world experience would 
be a a shortsighted folly, and tantamount to academic 
heresy. 

The simulation development lifecycle is an eight step, 


iterative concept. It is composed of the following phases: 


1. The Simulation Feasibility phase. 
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‘eee fgemoamilation Requirements/Specification phase. 

3. The Conceptual Simulation Desien phase. 

eee vetarted Simulation Design phase. 

2. The Simulation Module Creation phase. 

6. The Simulation Module Integration phase. 

7. The Simulation Implementation phase. 

8. The Simulation Maintenance phase. 
These phases represent a logical and systematic approach to 
Simulation. They are interdependent, but not necessarily 
Ssequemtdial. Sequential progress is an ideal and textbook 
path through the lifecycle. The majority of simulations 
generate feedback, which may dictate backstepping to review 
and revise a previously completed phase. Enveloping the 
Teme tiftecycle is the continuous VoNeH Neon and 
validation cycle. VerentTecati1on) 1S seomeerned syvith the 
relationship between the developing simulation and the 
Pusu dabaon specification. Validation refers to the 
applicability and value of the simulation to the actual end 
user. This verification and validation cycle permeates all 
aspects of the lifecycle, ensuring the simulation is being 
Gonmctmuc ted correctly, and that the correct simulation is 
being produced. 

The simulation feasibility phase includes the macro 

definition of the parent system, the performance of a 
cost/benefit analysis, answering of the rhetorical 


analytical/optimization method versus simulation question, 
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and a schedule analysis and preliminary development for the 
projected simulation project. Several GO - NO GO decision 
Bereecmare innerent in this phase. Also, the core members 
of the simulation development project should be assembled 
into a team during this phase. Neglecting to invest 
aoecimate Tesources (manpower, financiai and time) in this 
phase can build a weak foundation for the entire simulation. 
Systems analysis techniques can provide useful tools to the 
Simulation team throughout the feasibility phase. The y 
offer the flexibility to recognize technology and financial 
considerations, as well as handling much of the conceptual 
thought present in this phase. 

After a solid 'GO' decision on the simulation has been 
reached, the simulation requirements/specifications phase 
commences. Micrlaed herein is the parent system micro 
definition statement. This should encompass the limits and 
parameters, functions, purpose and effectiveness indicators 
Bomtemdravn from the parent system. All these qualities 
Meaowendmepe testable. This testability is critical to the 
momemdetionyverification cycle. ihe Si Mtieat Ole support 
environment must be comprehensively defined, and should 
incMmiGeMEnes support functions, interfaces, facilities and 
support performance measures. This is also the time to 
Scteauersch comcrete, Meacsiimeanile McdanU hata On project 
Bmbestomes. Fimally, the entire simulation project team 


should be assembled. Familarization training should follow. 
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Formation of a firm simulation project team in this phase 
may raise startup costs. Rowever s personnel stabalization 
and solid training provide protection against the occurrence 
Bemerooks s Law [Ref 11: pg. 25]. Throughout this phase, 
heavy end user involvement is integral to the production of 
verified and validatec requirements and specifications. 
Proceeding into the conceptual simulation design phase, 
eo wc@muration project team transforms and abstracts the 
Borenmt system into models. The previously defined 
Peagwarements and specifications provide the direction and 
guidance for this decomposition. Flow diagrams, in a 
standardized format, can serve as meaningful communication 
tools and form a documentation foundation. Lie vehe 
Pam@laron sponsors desire a prototype, it should be 
aecomepeiashed in this phase. The definitive statement of 
Support environment and simulation relationships is 
completed in this phase. Draft simulation users manuals, 
and test plans are assembled. This phase serves to bridge 
all preceding efforts with the remaining phases of the 
project. As such, a careful review of problem areas, with 
time parametered corrective action, is appropriate. 
Logically stepping into the detailed simulation design 
Phase, the simulation moves from a conceptual state to a 
carefully planned and structured development sequence. 
Micro support environment decisions are made. Precise 


definition of previously grey areas is finalized. 
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Documentation continues to grow, and should pOGcerajyere clear 
simulation decision chrcnology to date. Models are grouped 
into macro modules. heli tasks short. “oma ay s iciaghl y 
integrating the support environment with the simulation are 
completed. 

Entering the simulation module creation phase, the 
Piyaieal integration of the simulation and the support 
environment occurs. In a computer-based simulation, this is 
micemeranslation of the macro modules into complete, 
documented computer programs. Regardless of the underlying 
Support environment, the outcomes of this phase are the 
Simulation modules. These modules must be tested on a unit 
basis. The previously prepared test plans, reflecting the 
requirements and specifications, serve as the performance 
barometer for the modules. End user involvement in the unit 
testing reinforces the validation and verification phase. 

Upon satisfactory completion of module testing, the 
individual modules are assembled into a complete simulation 
system in the simulation module integration phase. Module 
[Meewmertace is a critical consideration in this phase. 
Likewise, documentation must be updated to reflect the 
module integration and related decisions. 

The simulation implementation phase involves placing the 
fully functional simulation system in the hands of the end 
iteweeeeincitticive in this process are on-site systems 


testing, user training and user feedback. This phase is the 
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acid test for the effectiveness of previous validation and 
Meriidcation cycles, While this step may appear to ode 
anticlimatic after the previous efforts, it remains integral 
tO ensttre that the users receive a debugged simulation, 
Meeerstand the operation of the simulation and are 
adequately trained in their role as simulation participants. 

Mmommcapateane to this lifecycle is the simulation 
maintenance phase. Commencing after the simulation is 1004 
Preldedyaidt COvers the gamut from correction of simple logic 
errors to complete revision and/or replacement of the 
Ttuedtion system. Historically, this phase is the most 
resource hungry portion of the lifecycle. Simulation 
Maintenance should be carefully accomplished in response to 
user requirements, take into account support environment 
constraints, and should parallel parent system evolution. 

To summarize, the simulation development lifecycle is a 
cradle to grave management plan for simulation systems. It 
intends to interject structure and direction to a somewhat 
fluid and wandering process. This type of organization and 
composition is purposely aimed at reducing the inherent risk 
present in this type of multi-dimensional project maangement 
effort. While it is not a guaranteed recipe for simulation 
puec@ecs, JE provides an organization with a solid penne Tonk 


fo mold and craft to each individual application. 
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Tit. PROBLEM DEFINITION AND INITIAL DECISION PHASE 


LL OK ES (— oes 


A. REVIEW 


Fromme the previous chapter, two central themes 
continually surface and merit restatement: 

1. A drive by managers to understand the meaning and 
utility of the AIS, as well as harness its power, is 
frequently being thwarted by the saturation of 
mainframe hardware resources and the lack of adequate 
hardware and software tools to meet the needs of 
decision makers. 

2. Simultaneously, many managers are seeking to exploit 


the capabilities of the microcomputer to enhance their 
cecrston making function. 


imntemouvmous intersection of these two tendencies is the 


Simulation of an AIS on a microcomputer. 


B. PROBLEM STATEMENT 

This intersection is the basic hypothesis to be pursued 
in this thesis. Specifically, this thesis will address the 
problem of using a microcomputer and related software to 
Simulate a mainframe AIS in a feasible and realistic manner. 
To probe this problem, the following sequential approach 
will be used: 

1. Software Determination: Through the use of a decision 
model incorporating user needs and requirements, 
software selection will be accomplished. 

2. Hardware Determination: Using another decision model 


reflecting user needs and requirements, the hardware 
selection will be made. 
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3. The Simulation Development: Through application of the 
Satertall model of the software lifecycie, the 
simulation will be designed, coded and implemented. 

fete st and Evaluation of the Simulation: A formal 
validation and verification phase, which encompasses 


the entire project lifecycle, will be executed to 


Bree the rightness’ and correctness of the 
simulation. 


During the course of this simulation development and 
meepleteation, several research questions will be 
mivestesated. Specifically, answers to the following will 


be sought: 


1. Are microcomputers technically capable of executing 
software packages that simulate a major AIS? 


2. What are the positive and negative outcomes associated 
with simulating a mainframe AIS on a microcomputer? 


3. What are the essential features that must be present 


Meters simulation to ensure that it is a 
representative model? 


4. How can an AIS simulation be designed and developed to 
maximize user satisfaction within organizational and 


technological constraints? 


5. Are microcomputer-based AIS simulations a viable 
Smedonetor future applications? 


fimemnrespective findings will be presented in the thesis 
eonelusion. 

The focal point of the problem statement revolves around 
the term ‘simulation’. Recalling from the previous chapter 
Miaeeceemriinary objective of simulation is to garner an 
understanding of the system and its related behavior, Eins 
thesis will emphasize this goal. This emphasis is driven by 


the resource sponsor of the project, the Fiscal Director On 
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Beewtiakine Corps, and the intended application of th 


(D 


resultant product as a training package for the Marine Corp 


i) 


merece Comptrollership Course (MCPCC). Further 
Mescussion of this matter is presented later in this 
chapter. 

The inherent mechanism of any simulation is the model. 
The model is merely a representation and abstraction of 
Pertailn features of the parent system. The key fact is that 
the model is designed to abstract and represent only certain 
features of the parent systen. TD 1S eases Domenbe da Ok 
meer eremtiation for simulations, as a simulation tends to 
iteatwewand spot directly emulate or replicate the exact 
behavior of the parent system. The extent and nature of 
this particular imitation will be explicitly addressed in 
the system definition phase of the simulation development 
lifecycle. 

ASm@meith any science, principles of simulation exist to 
provide humans with a solid, directional framework. This 
Simulation will be guided by these principles, as follows: 
Ret 6: 9p. 4] 

1. Principle: The simulation must be easily understood by 
Biemietimare end wser.  Applicatiom of this principle 
will be via the following methods: 

a. Explicit designation of a user group. 
b. Continuous and iterative communication and 
feedback between the user group and the system 


developers during all phases of the simulation 
development lifecycle. 
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Smee evelopment and implementation of a formal 
feedback loop after fielding of the simulation. 
Pegetemsi ites ton Must be geal cr chiecti 
dire eeeuvesoprainciple will be applied with the 
following methods: 


a. Development of a software decision model 
enveloping the user needs and requirements. 


b. Development opi a hardware decision model 
incorporating user needs and requirements. 


c. Specific user designation of simulation goals 
and objectives, commencing with specification of 
the system elements and components to be 
simulated. 


3. Principle: The simulation must be robust. Principle 
application will be through the following methods: 


icon peration of error modules into the product 


and detailed design phases of the simulation 
development lifecycle. 


b. Extensive simulation testing by representative 
users prior to operational fielding. 


Smeeewmre oration of hardware characteristics into 
piemoen-maechine interface of the simulation. 


fe Franciple: The simulation must be complete with 
mero omthne critical issues of the parent system. 
This principle will be realized with the following 
methods: 


mueeeonteend loading of user/developer effort.and 
communication in the system definition phase of 
the simulation development lifecycle. 

b. Integration of the critical issues of the parent 
system into the hardware and software decision 
models. 

In reviewing the above principles and the means to satisfy 


them, the importance of communication becomes self evident. 


This communication took the form of weekly meetings between 


47 





the user group and the system developers between April, 1982 
- December, 1983. Heavy initial emphasis and discussion was 
mavecste in the system definition phase, consuming 
approximately 2 1/2 months of this time period. This effort 
was complimented by selected user group testing of 
robustness of the system on a module-by-module basis. 
Lastly, the communication between the users and developers 
was two-way, iterative and not limited to the formal weekly 
meetings. 

The point to be gleaned from the preceding discussion 
Seeesimulatiom principles is that clear and continuous 
communication is the backbone of the simulation development 
lifecycle. It provides the direction and planning necessary 
to deliver a verified and validated simulation. The absence 
meouch communication is a certain indicator of incumbent 


hatlure. 


C. DETERMINATION OF THE AIS TO BE SIMULATED 
HiCenbiettrequisite decision in this thesis is the 
etenmaination of which specific AIS to SiMUlatewunis 1s “a 
Etclmmmem decision, as it serves to direct all future 
eHideOr tc. 
As with most decisions, the AIS simulation determination 
iecwis@monue1s a multi-faceted one. The actual decision 


PmOcesempErOveg) to be too intangible to™quantify into a 
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Becision model. However, the following decision factors 


mere evident: 


Be 


The AIS would be selected from a public sector 
application. Rationale for this choice are: 


7 oy weep ubiic sector organizations have a far 
PienomeNaeckpround in ALS operations than private 
Secrmon Lirms. 


Pee ececo tO 8 AlS information in public sector 
organizations is generally easier than in the 
Didi e sector. lites Sac ess. tow Lilt or tat ion 
ranging from source code to software design 
Seceotoles is Critical throushout the simulation 
development lifecycle. 


c. Both thesis authors have had moderate exposure 
Bompmbitcesector AIS's. This factor eliminates 
some of the AIS relearning usually required in 
the simulation development lifecycle. 


The AIS will interactively communicate with the user. 
Supporting rationale for this requirement are: 


a. Interactive communications intensifies the 
feedback loops between the user and developer. 
This is viewed as having a positive effect upon 
the simulation development lifecycle. 


b. Increasingly, computer-based simulations are 
entirely screen oriented. This screen 
orientation dovetails nicely with an interactive 
Ree, 


c. The entire realm of computing is evolving from 
batch to interactive processing. Selection of a 
batch oriented AIS to simulate might prematurely 
jemienoy any practical “applications of the 
Simulation. 


The simulation developers must have complete access to 
the entire parent AIS package. Supporting rationale 
Bom this factor are: 


a. The rationale ensures the presence of adequate 


information to allow simulation and to prevent 
emulation/replication of the parent AIS. 
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Peeetcn “access is integral to the incorporation of 
'Mmesenaction and information hiding in the 
Simulation development lifecycle. 


Mmoaelmis requirement ensures the simulation 
developers will be kept abreast of any changes 


Boece parent ALS during the simulation 
development lifecycle. 


eeiwemal > Must be DBMS oriented. Supporting rationale 
fOme this factor are: 


feomeatlier noted, the AIS trend is driftime in 
the conceptual direction of database management. 


b. Database orientation compliments screen driven, 
MiGcwiact! Ve WwSer Communication. 


eel vemrts Simulation must ultimately be applicable in a 
non-academic environment. Supporting rationale are: 


MP~enieseencOnSideration is critical to gaining a 
projyect Sponsor. Spomisorship as required 0 
provide the financial resources to procure the 
software and hardware assets. 

b. This linkage is personally important to the 


Siecis authors, due to their previous military 
backgrounds, 


6. The AIS simulation decision will be a language and 
Software independent decision. Supporting rationale 
More this factor are: 
a. This type of decision independence reinforces 
milemrecearch aspects of this project and the 
iiieure appaicability of results. 


Peer itre ta recognize this point might tend to 
unnecessarily delimit the scope of this thesis. 


These six considerations provided an analytical 
framework to screen AIS simulation candidates. ies 
analysis took approximately one (1) week. It produced three 


primary candidates: 
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Pemilarine Standard Supply System (M35): This is the 
Marine Corps’ new supply system for the operating and 


Seppore establishments. it is database oriented, and 

jmecended to Pewee a unlit orm Su 1 SvVetrem eco alt 
pp 

Marine Corps users. STS tueeractively drive neon d 


Bsecesiened to replace the current family of 2nd 
generation supply software with 4th generation 
software products in the Marine Corps. 


mies seamdard Accounting and Budget Reporting System 
Gwen): SABRS is the financial compliment to M3S. 
Again, it is database oriented and applicable in the 
operating and support establishment of the Marine 
Corps. Fourth generation software will drive SABRS. 


The PRIME Enhancement Project (PEP): PEP is a layered 
on enhancement to the PRIority Management Effort 
(PRIME), the current financial management system used 
in the Marine Corps support establishments. It is 
ieomemed to transform PRIME from a batem system to a 
user-perceived interactive system through the use of 
the ADABAS database management system. 


Closer analysis of these three candidates led to the 


selection of the PRIME Enhancement Project as the specific 


nS to Semeeeecn  'ie decision to simulate PEP is based upon 


the following: 


es 


M3S and SABRS are in the early development stages. 
Mme weonhtain Strong concepts which have yet to 
Materialize on a CRT. This level of development makes 
them too immature to simulate. PEP is currently 
Operational at several Marine Corps sites. 


Mepropeectesponson, the Fiscal Director of the Marine 
Corps, has a high level of interest in both 
microcomputers and the results of this simulation. 


femerestrictions on access to PEP code or software 
development documents exist for purposes of this 
thesis. 


Doctrinally, PEP is the bridge between many of the 
current Marine Corps' batch processing AIS's and the 
Deanne d, interactive AIS packages. Doctmane 
application includes the integration of PEP into SABRS 
as a primary module. 


Sk 





2. The PEP Development team, composed of Major R. Cowen, 
Dewte Goptain R. Robinson, USMC and Ms. B. Hiile, ar 
Semone ty supportive of this effort. This type o 
organizational backing is viewed as key to overcoming 
potential obstacles in the simulation development 
lifecvcle. 

Bemomes preceeding, a further description of PEP is 
required. PEP is an in-house development of the Commandant 
of the Marine Corps (Code FD) and the Central Design and 
Processing Activity, Marine Corps Development and Education 
wommand (MCDEC), Quantico, Virginia. It is a financial 
manager's system designed to permit interactive transaction 
_ooemeeamae batch update file with full editing, allow the 
user to view information in certain PRIME master files, and 
to permit supervisors to review and delete transactions, 
faeobaan table files and extract transactions. Bier is 
SUrre@eny operational at MCDEC and Marine Corps Logistics 
Base, Atlantic, Albany, Georgia. Application is planned for 
the remaining Marine Corps support establishment. 

From a software perspective, PEP is a layered on package 
to PRIME. PRIME is a second generation, COBOL based, batch 
oriented financial management system. PEP's source code is 
Written in NATURAL, the command language of ADABAS. ADABAS 
is a network architecture database management system. elle 
couples in-house written NATURAL programs and ADABAS 
functions/procedures to perform user-designated tasks. 


Historically, it is a logical step forward for Marine Corps 


software from the era of batch-driven, MARK IV inquiries. 


Dre 





Pam@ware-=wise, PEP is implemented on Amdahl 470/V7 
feamibame computers. It is oriented to the 24 line X 80 
column format and keyboard of an IBM 3270 terminal. PEP is 


supported by the OS 3/70 operating system. 


fee Loe USER GROUP 

itmuextelosical step in this project involved the 
formation of a user group. User group formation began with 
Bieme@ctanition of the actual users of PEP, and with the 
definition of the users of the PEP simulation. This duality 
of definition was designed to balance the needs of the real 
Meers ot PEF with the possible constraints facing the users 
of the PEP simulation. Following the user group definition, 
formal designation of the user group members would ensue. 

The actual users of PEP are the supporting establishment 
comptrollers and their staffs throughout the Marine Corps. 
This is a diverse group that containsfew demographic 
Ponmmomamaties. They are both military and civil service 
employees. Educational levels vary from high school to post 
master's degree studies. Age varies from 18 to beyond 50. 
Their work experience is likewise varied, ranging from entry 
level positions to the top financial management billets in 
their commands. Further isolation of common demographics 
for this group failed to produce any usable points. 

Meow tse cimualation users fell into a similar category. 


ite spropeet sponsor desired that the PEP simulation be 
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ieaieemmerect into the curriculum of the Marine Corps Practical 
Somperollershio Gourse (MCPCC). This course is conducted 
Pwree annugily at the Naval Postgraduate School (NPS). 
memgemese at the MCPCC come from financial activities 
Parougnout the Marine Corps. Their demographics are 
somewhat more identifiable: 
econ tating. 
a. Military students: An officer, WO-1 and above. 
b. Civil Service students: GS-8 and above. 


MeeeecmestMident Ss CUrrent billet must require or be 
related to financial management. 


3. student nomination is performed by the local command. 


Student selection is performed by the Fiscal Director 
Ouethe MWarine Corpse 


These demographics provided a somewhat tighter definition of 
who should compose the user group. However, practical 
considerations as to the availability of such personnel for 
meet vee pameticipation in a user growpy and the time 
constraints on system development prohibited the integration 
Or actial or perspective students into the user group. 
Mmresewsame considerations prohibited the integration of 
actual PEP users into the user group. 

Given this limit, it became necessary to examine local 
resources. Fhis proved to be a rich source of users, as 
numerous Marine Corps students at NPS have financial 
Management backgrounds. From this student inventory, the 


following user group emerged: 
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eajor &k. H. Myers, USMC: Major Myers was a student in 
the financial management curriculum. His military 
Baek eground included a varied supply and fiscal 


billets. He would serve as the head of the user 
group. 


eeeeanyor 0. Grimm, USMC: Major Grimm was also a student 
in the financial management curriculum. Wiahe 
background included experience at the Fleet Marine 
Force level of financial management. 
weeeeaptain S, GCG, Shumway, USMC: Captain Shumway, a 
financial management student, brought a rich variety 
of operational and supporting establishment financial 
management to the user group. 
These three financial managers composed the formal user 
group. lnueme@iversity and scope of their combined 
backgrounds provided the depth necessary to accurately 
represent the actual users of PEP and the PEP simulation 
users. 

Thus, the user and development groups were formally 
fecisemated. Additionally, Lieutenant Colonel J. F. Mullane, 
Jr., USMC became the defacto project manager of this effort. 
LtCol Mullane, the NPS Marine Corps Representative and a 
financial management instructor at NPS, provided the 
direction and guidance to mold the user and development 
groups into a formative project team. Also, he served as 
the formal interface with the project sponsor. 

This chapter has provided a broad overview to the 
Sommmoments of the probleno. iio Emnidsmmowbd1 ned) tne 


methodology and principal decisions made prior to the actual 


problem resolution. The remaining chapters focus on 


a5 
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ay 


micem@oac portions of this problem resolution, an are 


intended to highlight the types of decisions and tradeoffs 


inherent in this problem resolution. 
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IV. SOFTWARE 


pe, «OVERVIEW 


The use of a microcomputer to provide a simulation 
Support environment involves two integral and related 
components: hardware and software. This chapter will 
address the software issue. Hardware will be covered in 
merpueer  ¥, The software topic will be introduced in this 
meeemmwith an initial definition of the soitware 
Fequirements. This sector addresses the semantics of 
Moe tware requirements, the relationship of software 
requirements to the simulation development lifecycle, and 
the requirements rationale. The managerial source of the 
software requirements will also be identified. After the 
requirements definition will be a presentation of the 
software decision model. Included in this presentation will 
Mmemeifem model's purpose, it's structure, and a brief 
discussion of the modeling support environment. After the 
the software decision model has been developed, 12 foie) ig 
alternative software solutions will be introduced. 
Definitions, applications and examples, and the respective 
advantages and disadvantages of each software alternative 
will be detailed. All of the software alternatives will be 


evaluated with the software decision model. The objective 


of this process is to select the most desirable software 


Sy 





meecmm@ative, the chapter conclusion will be an in-depth 
review of the specific software product selected for use in 
Bae simulation and a concise description of the software 


acquisition process. 


B. DEFINITION OF SOFTWARE REQUIREMENTS 

When a consumer has a need, he visualizes a product to 
Satisfy the need. He refines the thought by clarifying the 
exact nature of his need, and developing evaluation criteria 
Pomejuaqee, alternatives that can satiate the need. This 
common need determination process, a sequence every shopper 
has gone through countless times, is analogous to the 
definition of software requirements in the simulation 
development lifecycle. A need is known to exist (software), 
and the concerned parties consciously consider how to best 
gratify this need through the definition of requirements. 

Moving from this conceptual perspective to more concrete 
ground: the goal of requirements definition is to create a 
complete, consistent and unambiguous specification of WHAT 
the software product will contribute to the simulation. 
This is) ag intentwional emphasis of the WHAT, as the 
corresponding HOW is the responsibility of the design phase 
Pace noe | |. Within the software requirements 
definition procedure, two terms are prevalent: requirements 
and specifications. Requirements tend to deal with the 


DUM mettlon Of Objectives and the understanding of the 
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problem. they are macro in scope. Specifications are the 
detailed description of what the software must be, in terns 
of functions and interfaces. Specifications tend to be more 
limited in scope than requirements. The relationship 
between requirements and specifications is comparable to the 
correspondence between strategic and operational management. 
Med@ueret@ents describe the big picture, where as 
Peommcatazons portray the situation from a more detailed 
level. Dteaclatwemcohip forms a natural hierarchy. 
Violation of this hierarchy can produce upheaval throughout 


Sie TPemaining phases of the lifecycle. 


The software requirements definition phase has a unique 
Meieeeeade relationship to the simulation development 
mmeecersetsc, This relationship is a direct function of the 


following: 


1. As previously noted, software is usually the most 
vulnerable component of a computer system. As such, 
Beetle presents the highest risk to any proposed 
project. This intensifies the need for a clearcut 
statement of software needs, relative to the proposed 
Syren back of proper definition introduces further 
Mmcertitainty to the software, and can produce a 
iment ive ripple effect throughout the lifecycle. 
To minimize this risk, software is routinely the first 
system component to be defined after the feasibility 
analysis. This approach appreciates the highest risks 
up front, and defers the more stable system components 
moma later decision point. 


2. the software requirements definmeeron provides a 
precise and clear statement of the software system. 
This generates a baseline for the validation and 
Mommercatiton cycles. Also, it provides a foundation 
For test plans and test procedures. 
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- ooftware requirements concretely define the ‘What' of 
the software. This is a requisite, sequential step 
that appropriately precedes the 'How' of the design 
phases. 

4. Lastly, the requirements definition is the user's 
explicit message to the developers. This must be a 
distinct and unclouded communique to ensure the users 
receive the desired end product. 

Within the federal government, requirements are further 
categorized as mandatory and desirable. Mandatory 
requirements represent absolute needs that must be satisfied 
meerme aqelivered product. Failure to fulfill a mandatory 
requirement eliminates an alternative from further 
consideration. Desirable requirements are features that a 
Peerewould prefer to have, but is not willing to apply as an 
elimination factor between alternatives. Generally, 
desirables are enhancement features to the basic product. 

Software requirements definitions flow primarily from 
the users, and supplemented by the developers. Eh ase gan & 
input to requirements tends to blend the user's desires 
and perceptions with the technical realities that the 
developers must contend with. In the PEP microcomputer 
Simulation, the previously discussed user group and 
development team served as the source of these inputs. 

Requirements definitions can assume three administrative 
Somemotrations: Informal, Formatted or Formal, The PEP 


mer ocomputrer simm@lation used the informal forn. It was 


deemed appropriate for the following reasons: 
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1. The degree of financial risk inherent in this endeavor 
was Mieco tclent to justity formatted or formal 
methods. 


2. With the presence of the parent system and the 
BUporeinme documentation, there was Aes Ue eae den ae 
Bepenhemea ! Tisk™ to use formatted or formal 
Sonar gurations. 

Coote ewe intormal requirements definition 
configuration, the PEP simulation software requirements were 
further categorized into general software requirements, 
software engineering related requirements, and database 
Den@innmes requirements. Each individual requirement was 
defined in plain language. The supporting rationale, type 


designation (mandatory or desirable), and the requirement 
source were appended to the definitions. 
Starting with the general software requirements, the 


following separate individual requirement criteria were 


developed: 


Weesddimement: The selected software must permit 
development of the microcomputer simulation in a 3 to 
4 month time period. 


a. Rationale: The lack of development team 
resources (two designers/programmers) drove this 
Eeqju@rement. The December MCPCC class 
implementation date defined the 3 to 4 month 
time period. Finally, this requirement was 
chosen to emulate the time compression present 


in many project management environments. 


b. Type: Mandatory. 


€. source: Joint input by the user group and the 
development team. 


2. Requirement: The software must be fully transportable 
between microcomputers. 
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a. Rationale: This requirement reflects the desir 
to potentially apply the product outside of th 
thesis environment, Also, it reflects the 
Gigrent tack of formally accepted micrecomputer 
standards within the Marine Corps. 


m «(D 
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b. Type: Mandatory. 


¢. Source: Joint input by the user group and the 
development team. 


3. Requirement: The software package must support 
documentation and data dictionary production. 


a. Rationale: This requirement is derived from 
Biome oninciple that "Documentation is the 
Software Product' in systems analysis [Ref. 14: 
npeeeeo. Also, it was included to support the 
MMcwwntaD Le future modifications to the 
Simulation. 


See lype; Mandatory. 
c. Source: The development tean. 


4. Requirement: The software must permit expansion and 
Gonmeraceaon of the Simulation. 


a. Rationale: As PEP is designed as a primary 
module of SABRS, this requirement is intended to 
facilitate the eventual simulation of SABRS from 
Polsmfotndatiton. Also, this requirement was 
Puceweided to aliow simulation upgrades to 
parallel any upgrades in the parent systen. 


b. Type: Mandatory. 


een DOr Ce: Joont Input stromethe user group and 
the development team. | 


>. Requirement: The software must support interactive 
programming. 


a. Rationale: Interactive processing is the 
fundamental element of the parent system. As 
such, it must be present in the simulation. 


b. Type: Mandatory. 


Cempoource; The user group. 
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6. Requirement: The Sottware” “mist, prowide time 
responsive execution on a conventional technology 


microcomputer. 
aeeeeskationale: The time responsiveness was deemed 
aiieecal to holdine the student's attention 
Gimmie anticipated system use, Also, time 


responsiveness was necessary to maintain a 
resemblance to mainframe processor response 
Eaae's . 


b. Type: Mandatory. 
Gemeoouree: The user group. 


ere dterement:; The software must support real time 
Simulation of PEP in a stand alone environment. 


Gnuenationale: This need was intended to minimize 
the complexity of system use for students. 
Student use was projected to be in hotel rooms 
or government quarters, where peripheral support 
would not be readily available. 


b. Type: Mandatory. 


Gemeoeurce: The user group. 


8. Requirement: The software WES 1S VSD) oye ie cal eng abt 
aeetracy LOr mantissa up to and including 1 * 10**8 
with with two decimal place formats. 


a. Rationale: iaes numeric accuracy is an 
essential element of the parent system to 
Simulate. 


b. Type: Mandatory. 
c. Source: The user group. 


9. Requirement: The SOtevare mw muUct Er acilditate sEne 
integration of security features e.g. passwords, unit 
designations from the parent system into the 
simulation. is 


a. Rationale: This was deemed an essential feature 
of the parent system to simulate. The intention 
is to familiarize the students with the security 
features of computers, and to foster thought on 
computer security. 
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tee apes Mandatory . 
c. Source: The user group. 


FPO. Requirement: cious. software should be prema by 
OamemtedybLowards non-tactical data processing. 


a. Rationale: This requirement was adopted to 
prevent the use of embedded software packages. 
Embedded packages tend to imply the presence of 


Tumettons i.e. device sensing, absolute 
reliability through software layering that are 
WEemeecr ici cal "to the simulation. Also, the 


embedded packages tend to tax the resource 
efficiency of conventional microcomputers due to 
the software redundancy. 


b. Type: Mandatory. 
c. Source: The development team. 
ime wnext requirements category focused on software 
engineering considerations. ims stepmewas a loci cal 
progression from the general software requirements. The 
resulting requirements packages were: 


1, Requirement: The software package must support 
Seeuceured programmine. 


a. Rationale: Inclusion of this need was designed 
to increase development team efficiency, permit 
traceability of flow in programs, and enhance 
the readability of the source code. 


be ieee ss Mandatory. 
c. Source: The development team. 


2. Requirement: The software package must support 
separate modular development of the Sam udaction. 


a. Rationale: This trait is desired to allow the 
implementation of discrete unit testing, permit 
a logical and learning curve phased development 
sequence, enable the simulation to embrace the 
reusable code concept, and permit the 
application of program stubs. Ndidive Mota ier y.. 
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modular development is the backbone of the 
GSomGceptwal design phase to the moduie 
integration pnase of the simulation development 
lifecycle. 


b. Type: Mandatory. 
c. Source: The development team. 


3. Requirement: The software package must allow the 
Mp hementation of information hiding. 


ee cmlmonale: <XIntormation hidine, the abstraction 
of common system functions and the subsequent 
Secessmeonstraints to the ‘How’ of the function, 
is critical to the separation of the design and 
module creation phases of the simulation 
development lifecycle. It permits developers to 
encounter complexity in understandable doses. 
Also, it will cause the simulation to present a 
realistic exterior to users and suppress the 
internal details from the user's view. 


b. Type: Mandatory. 
c. Source: The development tean. 


4. Requirement: The software must permit separate 
compilation/interpretation of modules and subprograms. 


a. Rationale: Mit ogertinecktoneis required to permit 
the timely completion of the module creation and 
module integration phases of the simulation 
development lifecycle. mdditvonaliy sit as 
needed to support top-down testing. 


b. Type: Mandatory. 
c. Source: The development team. 
5. Requirement: The software package must possess a 


GCmpuenenmsive library of built-in functions, and 
permit the development of user defined procedures. 


a. Rationale; This requirement is needed to allow 
system development within the defined time 
period. 


b. Type: Mandatory. 


c. Source: The development team. 
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6. Requirement: The soitware package must display 
understandable syntax errors, and contain logical 
error detection functions. 


a. Rationale: The presence of these 
characteristics is required to support the 
programming effort. Additionally, they will 
Sender osaid an isolating logic errors. 

b. Type: Mandatory. 

c. Source: The development team. 

The next component of requirements definition dealt with 
database handling requirements for the software. The 
following requirements were defined from the database 


perspective: 


1. Requirement: The software package must support numeric 
(integer and real), character and boolean data types. 


a. Rationale: The presence of these three data 
Mmese iss essential to the simulation of the 
parent system. Also, the presence of boolean 
data types is intended to support program 
fecisiton Dranenang. 

b. Type: Mandatory. 


c. Source: The development team. 


2. Requirement: The software package must facilitate menu 
driven query of the database. 


a. Rationale: This subset of the interactive 
processing requirement is needed to simulate the 
Inquiry module of the parent system. 

Deeetype; Mandatory. 


c. Source: The user group. 


3. Requirement: The software package must permit real 
time update of databases. 


eat ionale: This requirement was included to 
allow for the time compression of the pseudo- 
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interactive processing of the parent system. I 
mee eeCtS A COnNSci ous tradeoff decision to depart 
¢> 


meom tne acttlal characteristics of PEP in order 
Ooh ee Student S interest in a 
microcomputer support environment. 

b. Type: Mandatory. 


eam DOuUrce: Joint “inp: from the user group and 
development team. 


4. Requirement: The software package will project a 
logical view of the data, while supressing the actual 
physical data structure and linkages. 

eeeatwonale: This requirement incorporates the 
principle of abstraction and information hiding 
that are present in the parent system. Also, it 
recognizes the microcomputer knowledge level of 
the average student user and the potential for 
confusion with trivial details from the user's 
perspective. 

Peeeolype: Mandatory. 


c. Source: Joint user group and development team 
min put 


Collectively, these three categories of requirements 
femme 2o5eedistinct functional software specifications. 
Despite this broad base, three commonly included 
considerations were excluded: networking, database 
meee raty, and the structure of the database in the parent 
system. 

Networking was omitted because of the requirement for 
the simulation to operate as a stand alone system. As such, 
there was no forecasted need for networks in the intended 


application. 
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Database integrity was not considered, as the simulation 
Memeo ye @ardware definition a single user systen,. 
Additionally, it was envisioned that any potential database 
integrity problems could be eliminated by invoking a file 
Dotaweation Youtine at the ‘beginning of each user 
training session. 

Lastly, the structure (both physical and logical) of the 
database in the parent system did not receive any attention. 
Incorporation of this facet as a requirement would drive 
minor oyect in the direction of emulation, not simulation. 
PeesO,e tt Would tend to violate the abstraction principle 
meauarement. Finally, defining this as a requirement is 
really a statement of 'How' the simulation should operate. 
This disregards the 'What' concept of requirements, and 
Gowmaeserve to artificially limit the range of software 


alternatives. 


Peel ae SOFTWARE DECISION MODEL 

A multi-dimensional decision mechanism was considered 
PeMestE vehicle for integrating the 23 software 
requirements into a format that supported candidate software 
Poeodwet eValuation. AmaUantit iubise “decisions model was 
constructed using this mechanism. The objective of this 
decision model was to quantitatively evaluate various 
software alternatives. The previously defined software 


requirements formed the basis of this evaluation process. 
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Mitewsstructure of the software decision model is 
comprised of the decision criteria and the variables. The 
decision criteria represented the foundation of the model. 
iapetiis instance, the previously defined software 
mermmrements constituted the decision criteria. ea aes 
yielded 23 separate evaluation criteria for the decision 
model. Variables were used to assign a relative value to 
the respective alternatives for each decision criteria. In 
Mme ssOitwWware decision model, each alternative would be 
assigned a variable corresponding to individual requirements 
mene O to LOO range. A value of O would denote the 
complete failure of a software alternative to fulfill a 
requirement. Conversely, a value of 100 would represent a 
complete compliance with a requirement. Values between 0 
and 100 represent a partial requirement fulfillment. The 
assignment of these values, to the software alternatives, 
was the responsibility of the development team. The 
development team used the generally accepted characteristics 
of each particular software alternative as a guide in 
awarding these values. Pete neice Gl aye Sah oymnl foe Re lee 
PeWemaweeyeaccepted principles is contained later in this 
chapter. Upon value assignment for each decision criteria 
to all the alternatives, the values were summed by 
alternative to determine the total requirement value for 


each software alternative. Then, the total requirement 
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Maeeues OL each alternative was divided by 23. The result of 
this division was the mean software requirement vaiue for 
me saiternative, The software alternative with the highest 
mean software requirements value was the most likely 
candidate to be selected as the software component to 
utilize in the simulation, given no unforeseen complications 
Or circumstances. 

This decision model has several strengths. Foremost, it 
Mirrectiy incorporates the software requirements. 
mag@etonally, it is a fairly simple, two step solution to a 
multi-faceted decision. [Parc tl eee te hiaicmt nema nile re Ale 
Flexibility to recognize the strengths and weaknesses of 
each alternative. 

Conversely, a subjective weakness is present in this 
deterministic model. It relies on the development team to 
assign variable values. SUCKING elancemecoUld. GlLmini sh 
Smpectavaty and introduce bias to the decision. Enass 


potential drawback is present in any qualitative measurement 


model. The following factors serve to offset this possible 
Pitfall : 
1, The education and experience levels of the development 
eat. 


2. The alternative with the highest mean software 
requirements value will not be blindly procured. 
Rather, discussion with the project manager and user 
group will ensue. This review process is designed to 
test the validity of the model, and identify any 
subjectivity or bias. 
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MtewmesOrt Ware Cecision model was constructed in tke 
imeeractive Financial Planning System (IFPS) modeling 
language by Execucom. This support environment was selected 
because of its availability at NPS, for its ease of use and 
out of respect for the strong allegiance IFPS has in the 


corporate world. The IBM 3033AP computer, also located at 


NPS, provided the necessary hardware support. 


Meee tHE SOFTWAKE ALTERNATIVES 

The software alternatives were chosen from a generic 
merspective. MuGcther, they reflect the conventional 
microcomputer technology that is present in the hardware 
Samdidates. For DilmoOSeSe Of BEhag Ehesis, Ene term 
‘conventional microcomputer technology’ is definable by the 
presence of the following: 


Weercimary Microprocessor: A member of the Z-80 family, 
anme@eco, 6502 or 80186. 


Peer mm@any Operating System: Apple DOS, C/PM 80, C/PM 
commor MS DOS. 


Seems «COG hCUDto 671 2KB. 
This definition is a function of the hardware requirements 
Presented in chapter V, and the fact that this thesis has no 
requirement to push the leading edge of hardware technology 
pOmcanEtsny the project requirements. 
The conventional microcomputer technology constraint, 
coupled with other factors, eliminated the following 


Pie@ernarives from further consideration: 
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Meeeeerratiscidas Intelligence languages (LISP, Preiscg?): 
While interpreters and compilers are available, these 
S@mtrware packages lack the internal library of 
functions needed to permit the development within the 
Stated timeframe. Also, these packages routinely 


require RAM in excess of conventional microcomputer 
configurations. 


Z. Mainframe DBMS software (SEQUEL, ADABAS}: While these 
alternatives would have significantly simplified the 
development phase, there are currently no commonly 
marketed compilers or interpreters for these languages 
in the microcomputer realm. 

Sees A DA: mnCmenaCo h decent da fied). operational DOD 
eemeomrer for ADA, cotpled with its integral 
relationship with embedded systems, provided the 
reasoning to not consider ADA as a software 
alternative. Additionally, there are only non 
American National Standards Institute (ANSI) subsets 
of ADA, such as JANUS, that are currently available 
HOm Microcomputers. 

This elimination process produced the following four 
software alternatives for evaluation: 

1. Assembly Language. 

Pee hnen Order Language. 

3. Microcomputer DBMS Command Languages. 

4. Simulation Languages. 

Assembly language is a low level, processor specific 
language. fteerelies on Mnemonic codes to structure the 
language. These mnemonics have a one-to-one relationship 
with the machine language instructions that operate the CPU. 
This one-to-one translation produces two significant 


meester Fairst, it results in much more efficient code 


mane most compilers can produce. It also gives the 
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eee rammer airect control over the bare machine vie the 
M@ieae Mzcroprcecessor instruction set, Most high ieve 
languages do not provide an interface with the hardware at 
such a low level. These positive points create a second, 
disadvantageous result. A single line of high level code 
can invoke operations that might require anywhere from & to 
200 lines of assembly code. This type of relationship makes 
assembly language coding a labor intensive, error prone 
process. This negative condition has been partially muted 
Dy the development of macro instructions and subroutines. 
Macro instructions are single instructions which invoke a 
sequence of machine language instructions when executed. 
Subroutines are the application of the reusable code concept 
to assembly language. They have proven to be an extremely 
powerful tool when made available to programmers via a 
library. The library eliminates ‘reinventing the wheel’ 
when a common function i.e. sorting, square roots is needed. 
Another drawback to assembly language is the amount of 
complexity present. It requires a one-to-one interface with 
physical devices, and presents the programmer with a 
substantial mnemonics dictionary to grasp and apply. 

Despite this mixed review, assembly language remains a 
Secietewe amt LactoOr in the microcomputer market. 
Traditionally, microcomputers have had limited memory and 


processing resources. This physical constraint favors an 
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Permemcont coding method like assembly language. 
Somplimenting this efficiency is the increased device 
control achievable with assembly language. This enhanced 
device control can resuit in ‘user friendly’ interfaces with 
operators. The applications spectrum for assembly language 
covers the entire software gamut. Two prominent products, 
Ashton Tate's dBASE II and MicroPro's WordStar, demonstrate 
this variety. dBASE II is a relational database management 
System coded in assembly language. WordStar is an extremely 
popular word processing program that is assembly language 
based. Additionally, literally hundreds of system software 
applications, ranging from single task utilities to complete 
Operating systems, are source coded in assembly language. 
High order languages (HOL) are the backbone of 
traditional data processing. Structured with language 
specific syntax and operator definable semantics, HOL's are 
Semmverted into machine language by a compiler or 
interpreter. He Gempilter om interpreter effectively 
transforms HOL statements into machine language macro 
mietrm@ertons. HOL's have continually attempted to permit 
programming with English like words. HOL's are considered 
to be a fairly machine independent language at the 
applications program level. The dependency comes at the 
Somipesbere level, which is routinely linked to a mami] y oes 


processors. 
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HOL’s produce a windfall of advantages. First, they are 
Much easier to comprehend than their assembly language 
counterparts. Pee guentiy., a HO will “conmtain a broad 
library of functions and will support the execution of user 
Pwned precedures. HOL source code is more readable than 
assembly language source code. HOLs are more forgiving in 
coding than assembly language, and offer strong diagnostic 
capabilities to simplify program debugging. The net result 
of all these benefits is that HOLs provide a less labor 
intensive program development environment. 

moesmeare not without pitfalls. Despite several 
significant attempts, HOLs tend to reflect a clear and 
Mectmet Orientation. This orientation is a function of 
programming language design decisions towards a given type 
of application made by the language's authors. For example, 
Seeemeress particularly well suited for file processing. 
Powever, it is Picea nertenihvawnenemtised Lor sSerentific 
agoireations. The reverse tends to be true for FORTRAN, 
eel tomsctentifically slanted and inappropriate for file 
processing. APL is mathematically directed, as is ALGOL. 
Pascal originated as an educational language designed to 
emphasize structured programming and top-down design, and 
has evolved into several business application areas. fhe 
outcome of these examples and this orientation bias is that 


HOLs, when viewed individually, lack a true, general purpose 
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eo aeatiomws capability. PH/1, developed by IBM, is the 
Mest attemot to date to create a flexible, muiti-purpose 
MOL. 

Gitespresence of a compiler and applications programs 
create increased memory and processor requirements for HOLs. 
Likewise, many microcomputer HOL compilers are not optimized 
with regard to HOL - machine language transformation. These 
Prroeractors tend to cause HOLs to push the resource limits 
ee mwerocomputers. 

Deereeee Sthis;, microcomputer HOL applications have 
evolved and will continue to flourish. COBOL, FORTRAN, and 
Pascal microcomputer compilers are commonly available. 
Digital Research's PL/1 compiler is an industry innovator, 
as it produces better machine language optimization than 
most of its mainframe counterparts. An entire industry has 
developed around microcomputer games, many of which are 
Mritten in BASIC. Lastly, applications are frequently 
meeteten in HOL for microcomputers. These applications are 
Siren cot™piled to produce a machine language progran, 
commonly identified by the .COM filetype, and used in their 
machine language version. This approach realizes the 
Peer bi lity of an HOL in design and coding, while avoiding 
the need for a compiler and compile time at execution. 

Microcomputer DBMS command languages are applications 


development languages. Logically layered above the database 
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an the software hierarchy, such languages tend to explicit 
the query functions of the database manager. This approach 
allows for far reaching manipulation of the database. 
Coupled with this effect is the fact that these languages 
are relatively less restrictive in standards and semantical 
Beemuect ure than the previously reviewed software 
aiternatives. The result of this coupling is a powerful and 
imaginative tool that allows a user to maximize the ye Sh Aba ie 7 
of the database concept. 

Normally, a DBMS command language permits the user 
to define procedures, and supports structured programming 
and top-down design. Such languages normally use a DBMS 
compiler or interpreter to produce the machine language 
interface. Because they are microcomputer specific, they 
are routinely interactive and screen directed. They tend to 
emphasize abstraction, and present the logical, vice 
paysical view of the database and the hardware. 
Additionally, many DBMS command languages can access and 
execute non-DBMS command language programs e.g. assembly 
language utility programs and they possess limited ability 
to read non-DBMS data files. Perhaps the most valuable 
component of these languages is their effectiveness per line 
Seeehewcede. Drawing upon the internal DBMS functions and 
the structure of the database, a single line in a DBMS 


command language e.g. a file initialization procedure can 
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Maes tne same effect as 560 to 100 lines of HOL source code. 
Understandably, this macro multiplier characteristic has 
Beceived positive response from the marketplace. A final 
point is that microcomputer DBMS command languages bear a 
strong resemblance to their mainframe contemporaries. This 
momescervye to decrease programmer retraining in some 
Satuations. 

Despite these definite advantages, DBMS command 
manmeuaces are not perfect. Wee roring ene sdatabase 
meaidectUre, they are often intrinsically limited by this 
structure. This can serve to constrain the number of fields 
emeteGenda, and records per database. Aliso, the number of 
databases that can be simultaneously accessed can be too few 
to support the desired appli cataon. More importantly, the 
rampant popularity of DBMS and related command languages 
has spawned a cottage industry of ‘Ma and Pa' systems 
mouses. ieee th any new industry, the reliability and 
robustness of their products does not always correspond to 
the advertised results. 

As mentioned, the applications of DBMS command languages 
imeem widespread. Perhaps the most impressive example of 
broad acceptance of such languages is Ashton Tate's dBASE 


II.1 Independent market analysts estimate this product 


1 GBASE II is a registered trademark of Ashton Tate. 
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accounts for 704 of the micrecomputer DBMS market [Ref. 15 : 


Peete Using dBASE II as a parent database manager, the 


following systems written in dBASE II command language are 
currently operational: [Ref. 16 : pp. 138 - 141] 


Mm @ restaurant management system that performs 
Mibsemmory, Sales, payroll and invoicing functions. 
Wemmetoped by a part owner of a restaurant chain, it is 
Q@iewerely utilized in 20 locations within the chain. 


2. A student attendance system that provides real time 
information on pupil absence and tardiness, and 
peoemeeces corresponding reports. Users enjoy the 


improvement it represents over the previous systen, 
piidmeiiece the way it tracks student attendance 
patterns. 


3. A beauty shop management system that performs billing, 


collects sales data, aggregates cost accounting data 
and maintains general ledger accounts. 


4; <A political campaign management' system that tracks 
contributions and expenditures, does personnel 
management tasks for the volunteer campaign workforce, 
and provides prioritized appearance scheduling for the 
candidate. 


Peeessemedical system that collects information on 
infections developed by incoming hospital patients, 
does an analysis of the possible sources of the 
Mineetion., and recommends a course of action to 
locate, prevent and eliminate the infection. Users 
estimate this system produced annual savings of 
$150,000 during the first year of operation. 

Simulation languages are special purpose languages. As 
the name implies, such languages have the explicit objective 
oc  sanrdlat ion, Such tancuages trace their origins to 
mainframe computers and the science of mathematics. This 


family of languages has undergone an iterative and divergent 


development process. This development process has resulted 


Zo 


in the lack of strong commonality among modern simulation 
languages. Regardless, the following characteristics are 
merentitiable: 

1. Emphasis of abstract data types. 

Peeve ianeuage directly reflects the nature of the 
Somes OUS designdecisions directed toward specific 
Smieetewon techniques i.e. deterministic simulation, 
stochastic simulation, discrete simulation, continuous 
simulation. 

3. Simulation languages generally have a strong interface 
with system design languages. This relationship is a 
Hama gerial attempt to reduce the complexity of 
Simulation. 

4. Routinely, simulation languages have been derived from 
an existing programming language. This infers all the 
advantages and disadvantages of the derivative source 
are potentially present in the simulation language. 
iis .ts Not necessarily the case. 

As the preceding: characteristics infer, simulation 
languages are very flexible programming tools. They contain 
simulation development lifecycle aids, especially in the 
design area. Additionally, their integral design and 
Peaicrtres support simulation of real world events in a more 
comprehensive manner than the other outlined software 
pultememiaceaves. Lastly, they can access a myriad of non- 
Simulation language programs to produce a multitude of 
results. 

As might be expected, the price of simulation language 
flexibility and power is high. Normally, a simulation 


iimeimaee writ imply a 16 bit microprocessor, due to the 


increased RAM requirements of the language. i\olialal (eolroyele Esk ye = 
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Simulation languages tend to require instruction sets that 


are not always present on common microprocessors. This nas 


uN) 


(D 


PC mmme=Seompute:r Simulation languages to lack th 
programming richness of their mainframe relatives. 

IBM's General Purpose System Simulation (GPSS) is a 
moputar simulation language. Likewise, SIMSCRIPT is the 
other predominate simulation language. GPSS relies on a 
macro assembler for execution, while SIMSCRIPT is FORTRAN- 
based. (weeoewston of applications, ranging from cash 
register queuing models to complex environmental impact 
models, are written in simulation languages. Academic 
institutions tend to be heavy users of simulation languages, 
as they provide an appropriate environment to deal with the 
topics of higher mathematics and operations research. 

D. ALTERNATIVE EVALUATION AND SOFTWARE SELECTION USING THE 

SOFTWARE DECISION MODEL 

Using previously described methods, the software 
decision model was exercised. The results of the model are 
displayed in Appendix I. 

As the resulting mean software requirement values 
indicate, the microcomputer DBMS command languages represent 
the preferred alternative. Subsequent discussion with the 
Deomoctmmlatagen and the user group concerning the model 


outcome and software preference resulted in across the board 
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agreement on the use of a microcomputer DBMS command 
language for the simulation. 

The designation of a DBMS command language as the 
generic software package to employ led the development team 
to investigate and research current market product offerings 
in this realm. A two week market review ensued, and 
resulted in the recommendation of the dBASE II command 
language as the specific software product to procure. 
again a Giscussion of this recommendation with the project 
team followed. ihessdisectssion resulted in unanimous 
concurrence with the recommendation, 

The specific project rationale for selection of dBASE II 
as the software component of the simulation were: 

1. Based upon the previousdefinition of conventional 
picrocomputer technology, dBASE [ZT would not bias or 
constrain the hardware decision by being processor 
Or operating system specific. 

2. The expansive list of applications examples of dBASE 
Me —Ormneite the academic and commercial world, 
provided a compelling argument to the project team as 
to the capability of dBASE II for the intended 


appre ation . 


9. AS the model indicated, the features of dBASE II tend 
to be directly and positively related to the software 


requirements definitions. Sa data ma i y this 
relationship was strengthened by the presence of 
relational database architecture. ei oo deat ml 


relationship served as another convincing reason to 
selec, dBASE Il. 


4. dBASE II receives strong vendor and aftermarket 
support, and is readily commercially available. 


Peis tuiiy transportable in the conventional 
microcomputer technology environment, and produces a 
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Same rithve environment to apply the principles of 
software engineering. 


[aeemerespard to the proeturement of the commercial 


product, the process consisted of the following steps: 


ie 


A request, and a continuation sheet (SF 36) were 
nPomwended to the Purchasing and Contracting office. 
This request contained a justification of the need, 
the suggested retail price, and a recommended vendor. 


Based upon the suggested retail price, the Purchasing 
and Contracting office made several phone contacts 
ween Vendors concérning the product. This produced a 
ihtetmect price offerings from the vendors, which 
provided the vendor selection decision criteria. 


Mimewneurehasing and Contract office prepared the 
required contractual documents, and acquired the 
product from the vendor. Likewise, these documents 
entered into the appropriate financial systems for 
obligation and expenditure purposes. 
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V. HARDWARE 


A. INTRODUCTION 
One of the basic objectives of the PEP microcomputer 

simulaticn was to parallel the lifecycle development 
process of a major system . Adjustments in scale and scope 
were made, in accordance with thesis guidance, to achieve 
this objective. Appropriately, the system lifecycle process 
was analyzed to identify the hardware related phases of the 
PeeG@ecss.eenAs a result of this research, it was determined 
that the integration of hardware into a major system project 
may be described in four distinct phases: 

1. Selection and Evaluation. 

Pere auisition. 

3. Implementation. 

ea aaintenance . 
The above phases were used as a guide for merging PEP 
microcomputer simulation hardware with application software 
to forge a complete working system. | 

This chapter will examine each of the preceding hardware 

system development phases, first by discussing the 
principles of theory that are associated with each phase, 
and second by providing the development team's experiences 


with the execution of each phase. This approach was used 
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Semper ad@era Casis of Comparison between ecademic theorr 


. 


and what is commonly referred to as "real world” encounters, 


B. HARDWARE SELECTION AND EVALUATION 


Many consider that selecting the right computer hardware 
CoO support a given application is the most critical element 
moreaesuccesstul completion of a major system's project. 
miwommice validity of this statement is debatable, it is 
certainly true that making the right system hardware choice, 
in the initial system design stage, will have a tremendous 
mpateteom the success of the project. This impact can be 
Beactred sin terms of man-hours allocated to the effort, 
eventual effectiveness of the implemented system and total 
System lifecycle cost. 

The hardware selection/evaluation phase can best be 
defined as a process by which alternative hardware 
configurations are examined for suitability, with respect to 
measurable evaluation criteria. A single hardware mix, 
Pe@eesentines the optimal solution within problem constraints 
is thus defined. 

Imeomeeetinteion provides a lead-in to the first 
principle of hardware selection/evaluation: 


1. Principle: Regardless of the methodology that is used 


@omececelscte a particular hardware configuration, a 
quantifiable set of evaluation criteria must be 
developed as a means of establishing proof of 


hardware correctness for a given application. 
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The danger in violating this principle is that hardware 
selection will be based on some arbitrary set of evaluation 
Criteria, which may or may not have any relevance to solving 
Poe problem at hand. Dit csesttiationmoLten occurs when 
personal bias is introduced into the hardware selection 
decision by the system developer, the user, or a combination 
of the two. This bias can manifest itself in numerous ways. 
There is the “leading edge of technology" bias that 
eliminates all hardware proposals which do no represent the 
state-of-the-art in technological advancement. There is the 
Eleewamt the biggest and the best" bias that does not 
recognize the overhead costs associated with maintaining 
under utilized capacity or seldomly used features. There is 
the "strength in numbers" bias that bases system hardware 
selection on what everyone else has without considering the 
unique aspects of the problem that has to be solved. 


The potential consequences of violating the quantifiable 


mesults principle are: 


i Iterative system design concepts of validation- Are we 
PGididime the right system?, and validation- Are we 
building the system right? are not supported. 


2. If the hardware does not perform as intended, it is 
almost impossible to go back and determine what the 


original rationale was for selecting the hardware in 
the first place. 


3. Perhaps the most important consequence is that 


correcting hardware selection mistakes after the 
hardware has been acquired and put on line is 


generally very expensive. This may require the user to 
change the original scope of the project, or absorb 
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tne opportunity overhead costs that are generated due 
to the system's lack of expected effectiveness. 


Peoweatty tollowing the quantified results principle is 


ne usage oriented principle: 


Zeer rinciple: Hardware selection should be based on its 
MItweeO SuppOrt a specific application(s). 


The risk of user dissatisfaction with selected hardware 
will tend to increase if the hardware is chosen to support a 
made spectrum of applications when the nature of the 
HeineGements indicate that specialization is required. 
(eomatmimres this principle can result in loss of overall 
system efficiency. This type of loss is normally the result 
ef cost minimization. Through this lowest cost mindset, the 
amortized cost savings frequently are less than the 
cumulative cost of lost system efficiency. This scenario 
can result when hardware is selected as a universal cure-all 
Pee erymapplication. The reality is that every decision 
implies tradeoffs. Very often, general purpose hardware is 
not capable of performing specific tasks with the degree of 
efficiency that will satisfy the needs of every user group. 
An example of this general versus specific trade off is 
evidenced when a general purpose computer, commonly used in 
Picwmeccmapplications;,; is employed in a scientific 
environment. Although the general purpose machine is 
Gameepeweo or executing scientific applications, there is an 


incremental transfer cost in terms of efficiency that may be 
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Breater than the incremental benefits that are realized when 


is used to perform both functions. It may be 


@ 


' a Ws 
Mec Mac io 
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Heieeect ty acceptable in certain instances to select hardware 
to be used in support of multiple applications. However, 
the system developer needs to be aware of the advantages and 
disadvantages that result from this course of action. 

Change is a fundamental variable in any environment, as 


reflected in the following hardware principle: 


Pemeerrainciple: Selected hardware should be flexible 
enough to adapt to predictable changes in application 
scope. 


In keeping with the analogy of death and taxes, it is 
nearly certain that once hardware has been selected for a 
given set of application requirements, those requirements 
will grow to require additional hardware resources. If the 
selected hardware cannot be expanded incrementally to 
satisfy these new applications demands, are two 
possibilities will result. Either the new demands will go 
aeaIteiomied, which can result in user frustration and 
dissatisfaction, or a completely new system will have to be 
purchased to encompass both the old and the incremental 
Bigereemmames., This approach is usually cost prohibitive, 
based on the original system's lifecycle cost. The validity 
of this principle is evidenced by the fact that most market 
conscious microcomputer hardware vendors sell products with 


physical and logical expansion slots. 
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C, HARDWARE SELECTION/EVALUATION DEVELOPMENT TEAM ADAPTATION 

The three preceding principles directly influenced the 
meetston making process used to select the hardware 
component of the PEP microcomputer simulation. The first 
principle to be invoked was that of defining the application 
mame hardware would have to support. Before any real 
hardware alternatives were discussed in any formal sense, 
the exact nature and scope of the simulation was obtained 
Erom the thesis advisor and the user's group. leheles 
information was developed iteratively so that all parties 
concerned, the thesis advisor, the user's group, and the 
development team, could be assured that the objectives of 
the PEP simulation were clearly defined and understood by 
all. Once the simulation objectives had been finalized, 
they were transformed by the development team members, in 
conjunction with the user's group, into a more detailed set 
of objectives referred to as a functional specifications. 
As the decision to use dBASE II as the software component of 
the simulation had been made, the following software-driven 
minimum hardware requirements were produced; 


lL.) Ree Tmo Tomb camp ocesiscors, 126 KB for 16 bit 
BEOCeESSOrs. 


2. Divek Drives: Two, to allow for segregation of 
applications and systems aspects of the simulation. 


Dee esemidpacity; At a minimum, 200 KB per formatted 
Gaisik 
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a. Operating Svstem: Previously defined within the 


S 
conventional microcomputer technology philosophy. 
dese situnctional specifications were used to invoke the 
quantifiable evaluation criteria principle. With complete 
See iittion of the simulation objectives and functional 
specifications, the development team was able to identify 
am@ rationally evaluate hardware configurations from 
different vendors. A two dimensional matrix was chosen as 
meme Dasic evaluation format for the different hardware 
products. The first evaluation step was to compare each of 
the hardware alternatives from a common reference point. 
This point was determined to be the mix of hardware that 
would satisfy the mandatory requirements of the functional 
specitications. These mandatory hardware requirements 

mie lid ed: 

1. Screen Size: 80 columns by 24 lines. This was deemed 
essential, as the parent system was implemented on 
terminals with these characteristics. The user group 
peovwwued this requirement. 

Ze Toni tor Size: 9 inches diagonally, as a minimum, 
This was included to consider eye fatigue and 


readability of the text in the simulation. Again, the 
user group provided this requirement. 


See loraleHardware Cost less than $3000.00 per unit: This 


meeected the resource constraints of the project 
Semesor, amd the fact that four stand alone 


simulation microcomputers were desired for the MCPCC. 


4. Local Maintenance Support: This requirement was 
designed to minimize the risk of not having the 
deliverables ready for the December 1983 MCPCC. It 
was driven by the development team. 
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Next, Poe SOEaL cost for each vendor's particular hardware 
Merieieiration was calculated. The matrix was designed to 
evaluate different vendor's hardware configurations based on 
Doren Qaiantitative and qualitative data. The quantitative 
data was intended to provide a barometer of hardware 
performance in terms of capacity i.e. disk storage, main 
Memory, monitor sizes. The qualitative data was used 
to access the relative benefits of the different features 
associated with each vendor's hardware. These different 
meatires fell into the category of desirables, and included 


the following: 


iweeevemaled Software: This was considered, as it offered 
MmemmopportUunity to explore other potential 
ape icatioms for this hardware outside the realm of 
this thesis. 


Peectaphics Capability: While not essential, this feature 
meomerimctluded due to its value in a teaching 
environment and in management communication, 


3. Numeric Keypad: This item was included, as it would 
reduce data entry problems during training sessions. 


feiectsened as a Portable: This was included as a 
Geceaple because of the anticipated out of the 
classroom use of the simulation. 


Seletachabple Keyboard: Again, this was included to 
enhance the ergonomics of the machine. 


6. Hard Disk Capable: This was included due to the 
mumerent speed of a hard disk, and due to the 
anticipated system program and file size. 


7. RAM Expandability: Again, this was included due to the 


processing speed enhancement potential that it 
represented. 
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A subjective weighting system was used to convert desirabie 
feature characteristics to numerical values. These values 
would serve as the evaluation mechanism. The underlying 
strategy for using this approach was to calculate a hardware 
performance to price comparative index for each hardware 
Bentiecuration. This index could then be used to determine 
which hardware configuration represented the best value for 
each dollar expended. Pitmener edt would permit “a 
hierarchical ranking of alternative hardware configurations. 
Although portability was specified as a hardware constraint, 
configurations that were not specifically designed as 
portable were considered in the evaluation process. 
Rationale for inclusion was to determine if any significant 
tradeoffs involved with the use of portable hardware as 
compared to desktop systems. 

The development team gathered the necessary data for 
different vendor's hardware offerings and their associated 
Market cost by conducting personal visits to established 
mepeaeienout lets, and by researching appropriate trade 
journals. Once that data was collected for each hardware 
system, it was run through the evaluation matrix. As a 
mesult, the KAYPRO 10 was found to have the highest 
performance-price index and was consequently selected as the 


most desirable hardware system to support the PEP 
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Mmoectocomputer Simulation. The evaluation matrix anc the 


memiernes Of the other systems are displayed in Appendix 2. 


Be ACQUISITION 


Meeervali the hardware alternatives had been evaluated, 
amd ae particular configuration was selected, it had to be be 
Seytained Erom a vendor(s). Acquisition can be defined as 
the process by which an organization secures delivery of 
equipment and material from a vendor for use in a previously 
defined end application. [Ref. 17: pg. 154] This generic 
Se eeeton 1s applicable in describing both public and 
private sector acquisition processes. However, the remaining 
Meoetsccion of hardware acquisition will emphasize the 
process employed by federal agencies and the military 
services. 

The major criticism that has been directed at the 
Federal Government's acquisition process is that it is 
Mmmecesscarity complicated. As a result, it is often 
considered to be non responsive to user procurement needs. 
Procurement delays that are caused by a cumbersome and 
inefficient acquisition process can have a significant 
Mepaet eon tne success or failure of a systems project. fThis 
is especially germane with ADP equipment, due to the rate of 
PIeime re owecal change. Yesterday's competitive edge and 
productivity coup can turn into today's opportunity loss if 


enough time transpires between the project initiation and 
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ee 


actual receipt of equipment. The acquisition process the 
Federal Government uses for major ADP procurements has been 
consistently rebuffed for the time that elapses between 
formal need identification and equipment receipt. This 
excessive delivery time lag often results in equipment that 
is technically obsolete by the time of receipt. 

One of the primary reasons the Federal Government's 
acquisition process is so awkward is that not only does one 
Pave seo comply@with awbureaucratic hierarchy of rules and 
regulations within a given department, but these rules tend 
to overlap between different departments i.e. fiscal and 
supply. Successful completion of a procurement cycle, from 
the formal identification of a requirement to the actual 
receipt of the the equipment, involves interfacing with two 
separate staff communities: finance and supply. Each of 
these communities have their own regulations that deal with 
material procurement. 

The acquisition process involves the commitment of 
Memanc@al resources, and the services of the contracting 
branch of the supply department. The process normally 
commences with the formal identification of a new 
mera i ve stated dn monetary terms by a POM (Program 
Objective Memorandum) submission. The POM is used as a long 
range planning document which serves to highlight the fact 


that proposed special projects will require funding peag 
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cmeexomweed. The financial phase of the acquisition process 
mombinmwes, given project approval, by incorporating the 
meovaously identified project costs in the budget 
Ewomassion, The project may be given a separate line item 
as in the case of a major system development, or might be 
eycluded as a subset of more general classifications of 
financial resource requirements. Regardless of the method 
used to identify project funding requirements, the budget is 
the vehicle that is used to show the planned allocation of 
Peanetal resetrces, for a given appropriation type, by 
Mepotreclassification of expense, for the life of the 
Mmeprepriation. If the project survives the budget review 
process, funds are subsequently made available for 
obligation purposes. The process from POM submission to 
actual project funding can span as much as three years or 
more. 

[itemmscomtracting portion of the acquisition process 
commences once the project funds have been identified and 
Made available for obligation. The contracting portion of 
the acquisition cycle typically receives the most criticism 
with respect to procurement inefficiencies. This criticism 
Meemtetomeethe fact that the contracting office that must 
comply with all the rules and regulations that govern 
equipment procurement. These rules and regulations can be 


quite complex, depending on the magnitude of the acquisition 
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project. The magnitude is usually determined by the life 
@yele cost of the procurement. In the category of ADP, 
certain procurement rules have received a considerable 
mmoume of notoriety such as the Brooks Act, OMB Circular A- 
109, GSA (General Services Administration) directives, and 
mamerous ,other military peculiar regulations which are 
listed in the Defense Acquisition Regulations (DAR). 

It became apparent, as the federal government's 
acquisition process was researched, that two principles 
could be developed to positively influence an acquisition 
from start to finish. These principles were identified as 
Pollows: 

MPeeGmewmle: Start the acquisition process as soon as 
possible. 

Meeeecimciple: Once the acquisition process has been 
Seemted. insure that the project is continually 
Monitored, through each phase of the process, and 
imitiate corrective action when necessary. 

E. ACQUISITION - DEVELOPMENT TEAM ADAPTATION 

The development team realized that a careful and 
comprehensive acquisition strategy was needed to 
successfully procure the selected PEP simulation hardware. 
The resulting acquisition strategy was based on the 
aforementioned principles. 


The first part of the strategy involved converting 


system hardware requirements into estimated funding 
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requirements. Po esmmubation hardware cost eStimates were 
obtained by researching the current market price for each 
Pememeiem of the selected configuration, and then by 
extending the price for the identified line item quantity. 
Each extended line item price was then totaled to determine 
Boe Smystem cost of the PEP hardware procurement. This 
budget estimate was forwarded to the project sponsor for 
review and approval. The intent of the entire PEP budget 
formulation and review process was to identify and obtain a 
source of project funds. It was assumed that the 0 & M,MC 
appropriation would be used to fund the project vice PMC due 
to the original scope constraint that a given line item cost 
not exceed $3000.00, and the established project completion 
fecemelhe Accounting Branch, Code FDA, Fiscal Department, 
Headquarters, Marine Corps agreed to support the PEP 
simulation project with funding equal to the costs that were 
identified in the budget estimate. tii seaindine aAubhori ty 
Bade it possible to proceed into the next phase of the 
Sequasition process. 

Armed with appropriation data, the development team was 
able to initiate the actual procurement of the desired 
hardware configuration. This involved a considerable amount 
of interface with the NPS purchasing and contracting office, 
Mechs a Maivision of the supply department. The 


appropriate requisition forms were obtained, and the 


oe 





designated hardware was submitted for procurement action. 


The total cost of the requested hardware, while under tinh 


08) 


investment appropriation threshold, was beyond the thresnold 
for sole source procurement. This is where the development 
team got its first experience with the bidding process that 
is used promote competition. Three vendors submitted bids 
for the requested material, and, in keeping with the lowest 
cost to the government philosophy , the lowest bidder was 
awarded the primary contract. A second vendor was selected 
to provide a system development prototype machine. The 
DPrmm@ary COntract involved the procurement of four KAYPRO 10 
computers and designated peripheral devices. The system 
Prototype contract involved the procurement of one KAYPRO [II 
Gtemme and its peripheral devices. The KAYPRO II was 
chosen as the prototype development machine because it was 
mueedesecond to the KAYPRO 10 in the hardware decision 
matrix. The duration of the entire procurement process was 
seven months, commencing in July 1983. Completion occurred 
in March, 1984. 

The second principle of systems acquisition was applied 
extensively during this time frame. A considerable amount 
of time was spent by the development team conducting follow 
up procurement action to ensure that the prescribed delivery 
dates for the hardware were met. The success of the PEP 


Samubatton project was intimately linked to having fe 
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@eamesteda hardware available for the systems development 
during the July - November 1985 period. There was very 
mie stack for project delays due to hardware 
mmavadiwapility. This was driven by the proximity of the 
Mmeguetieed software completion date to the MCPCC 
implementation date. Continual procurement followup action 
by the development team was absolutely essential to having 
Mere tar dware delivered at the right time, in the right 


ferret ties, and in right condition. 


F, IMPLEMENTATION 

This is an extremely sensitive phase of the system life 
eyele. Despite the quality of preceding work, a poor 
implementation can lead to the death of an otherwise healthy 
project. Implementation can be defined as the transition of 
a system from a conceptual design into a physical and 
concrete working system [Refl8 : pg. 78]. Implementation 
normally involves two integrated yet distinct components 1) 
hardware, and 2) software. An implementation strategy will 
Normally determine how these two components will be managed 
meen regard to their time phased introduction as a working 
system, In some cases, hardware and software are treated 
as separate entities, despite the fact they are intended to 
function together as a system. This is governed primarily 
by the amount of complexity that is associated with each of 


the respective portions of the system, and the projected 


ae, 





organizational impact of the system. For large, complex 
oy seems, 1 is often necessary to initially accomplish tie 
Titre amipliementation first and get it functioning 
correctly. Next, the software implementation is addressed 
as a separate process. ines type of SitWation occurs 
normally when major system projects are initiated. Human 
beings are only capable of effectively dealing with a 
limited amount of complexity, as measured by the number of 
events that require simultaneous management action. Often 
res wocHemcgevelopment which involves the concurrent 
implementation of both hardware and software is simply too 
Coumplicated for one person, or group of people, to 
Seicdeuively @m@ianage, This sort of complexity is normally 
dealt with by breaking up the problem into smaller, more 
Manageable pieces. imine case Of a Major system, this 
involves splitting the hardware and software implementations 
into separate, related management efforts. 

The implementation strategy for less complex systems is 
markedly different from complicated systems. ft is uswally 
possible to manage the simultaneous integration of hardware 
and software. This is often the case when the software does 
not have to be developed without precedent, is commercially 


available, or does not represent a complicated programming 


effort. This type of system can be brought on line as an 
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integrated package more readily as many of the encountered 
implementation problems can be managed with relative ease. 

Although a system integration can involve both hardware 
and software issues, this discussion will focus on the 
hardware related issues. From a hardware perspective, there 
are usually three management problems that effect the 
Nardware implementation: 1) file conversion, 2) parallel 
ememaerons, and 3) people, i.e. user involvement. Each of 
these issues will be addressed separately. 

Most complex systems must interact with or be overlaid 
by existing data files. When new hardware is introduced 
from a different manufacturer than the existing system, it 
folie st anevitabile that some type of file conversion 
Preecesss will be required. This can be a very risky, time 
consuming, and expensive process depending on the degree of 
,om@onreincompatibility that exists, and the size and 
quantity of the files requiring conversion. software 
COMP=ersiomw costs can play an important part in the vendor 
Meermoton, For instance, even if a vendor clearly 
fanutactures a superior product in terms of computing power 
relative to the organization's current equipment, software 
conversion costs might be sufficiently high as to negate any 
potential benefits that might be enjoyed by using the new 
vendor's equipment. Consequently, an organization will tend 


to remain with one hardware manufacturer even if the product 
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that manufacturer produces is less capable than other market 
Seeeciigs.  Liis approach is a simple plan to avoid the cost 
oe Somtkware comversion. This is a routine decision 
consideration in private industry. The Federal Government 
does not consider these costs to the same degree, in the 


interest of fostering increased hardware competition in the 


market place. 

Piva tiem towthe cost of converting software, there 
is the technical risk associated with the conversion 
process, Many manufacturers provide utility programs that 
help with the conversion process. However, the reality of 
the situation is that software conversion from one hardware 
type to another often does not proceed as smoothly as might 
be advertised. The resulting consequence of this is 
mPrequent lyethat the user must correct conversion problems 
using in-house personnel. This usually translates directly 
into unbudgeted project costs. There is nothing more 
disheartening than pressing the button to run the new 
system, after the conversion process has supposedly been 
completed, only to get an error message back from the 
Gemputer such as "CAN'T READ eFILE”. 

Cnemectmmmene ~most difficult aspects of hardware 
impWementation iswdeveloping a strategy to accomplish a 
smooth and cost effective transition from the old hardware 


tome hee new hardware. There is a delicate balance that must 
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be struck between a cautious but costly approach to system 
phase in, and switching to the new system before it has been 
proven to be operationally ready. The cost of running dual 
meses Cad be Significant, and every realistic effort 
Bmowle pe made to minimize this cost. However, the 
consequences of abandoning an old system and switching to a 
new system before it is capable of handling an operational 
load can be devastating. This has especially been the 
Saccmwrth Many movice microcomputer implementations. 
Experiences abound where a vital business function, such as 
accounting, was converted to a new computer system before it 
Was proven to be reliable. In the worst cases, no recovery 
provisions had been made to use the former system in the 
event the new system failed pacer iic abe It would seem 
evident that if there was any question as to where the 
fulcrum of the balance should be put, it would be better to 
incur some inefficiency costs due to unnecessary parallel 
operations, rather than risk a complete collapse of the 
function all together due to system debugging problems. 
People, as with most management related issues, play a 
very important part in the over all success or failure of a 
HawOGbeesystem initiative. eniteeek acc k no matter how 
technically eloquent a given system is, it will be the 
PeGpeecmwumcemi me users of the system that will determine if 


Ehe Witiative succeeds or fails. There have been many 
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documented cases where a given system project looked good on 
Paper, DUL, as a result of poor implementation procedures, 
failed to gain acceptance within the organization and went 
unused or was under utilized. The implementation mistake 
that is often made with hardware is that systems designers, 
who are themselves very familiar with the hardware, fail to 
hecoem ze that the users may not have had any prior 
experience with the hardware. Users need information to 
umnx@erstand ™ what the intended function of the hardware is, 
and how it is supposed to be used. Terms that the systems 
designer may be very comfortable with such as disk packs, 
channels, main memory, and graphics terminal may be totally 
foreign to the end user of the hardware. The user may speak 
Tieeemmamor cash flow, stress points, outstanding TAD, which 
may be alien to the systems designers. A successful 
hardware implementation requires that users be interfaced 
with system developers during the implementation process. 
Under ideal conditions, this interface would be accomplished 
by establishing comprehensive training programs that users 
would be required to attend. This training would be 
supplemented by documentation in the form of a users manual, 
written in response to the user's need for information. _If 
Pe oerces tole fo train the wsers prior to the formal 
implementation of the hardware, then the users documentation 


must be particularly good to insure users understand what 
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the hardware is supposed to do and howto use the hardware, 
Often, systems designers will write the users documentation. 
ime pweblem With this approach is that system designers 
frequently introduce their hardware familiarity bias into 
tere rs docusmentation manwals and tend to make false 
assumptions about the level of expertise of the target 
omudienceweAs a result of this bias, they fail to provide 
the information the users need in the proper format. The 
consequences of this are that users will: 
1. Get frustrated and not use the system, 


Zesce Bele System, wut well not take advantage of 
Puente capabilities, 


Peel oyeand come up with procedures based on trial and 
er rier . 


4. Obtain less sophisticated but understandable hardware 

that may not be as capable as the system hardware. 

The current boom in microcomputers on manager's desk, 

while a large mainframe sits in the Data Processing 
department, is a prime illustration. 

Many of these problems could be avoided if users are allowed 


es cemely —participate in the hardware implementation 


process. 


G. IMPLEMENTATION -—- DEVELOPMENT TEAM ADAPTATION 

The primary and secondary contract items were received 
in accordance with the delivery schedules of the respective 
pomtaaemea, |lhe first item of hardware to be used directly 
Dimoemier rc LOcomputer Simulation project was the 


pegtorype KAYPRO ITI machine. The machine was used to 
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[ieeeeop a2 quick working prototype of the actual PEP 
Gmeerocomputer simulation project. This equipment was 
received at the end of July, and work was immediately begun 
on the PEP prototype software development. There were no 
parallel operation considerations to deal with as the focus 
of the implementation was primarily to become familiar with 
the hardware, and to obtain preliminary system performance 
data in terms of main memory, off line storage requirements, 
and system response times. The short term implementation 
goal of the prototype machine was to have a working skeleton 
of the actual PEP simulation available for a demonstration 
for the August, 1983 MCPCC. It was also intended to test 
the portability aspect of the hardware by taking the 
Dmetotmype System to a test site at Camp Pendleton, 
Sa vigeornia, where Bicwaomualee re system was being 
installed on mainframe hardware. Theeemtrip allowed the 
development team to evaluate the robustness of the PEP 
Simulation hardware, and provided an important opportunity 
Pome ctmman Cyewitness look at how the parent system 
functioned. More information concerning the software 
mpiereatioms of the trip wil be provided in the chapter 
covering system development. 

The primary hardware items, four KAYPRO 10 computers, 
were delivered in September, 1983. This equipment, while 


still part of the same family of hardware as the prototype 


106 





machine, represented an entirely different architecture in 
terms of execution speed, off line storage formatting, and 
disk capacity. This hardware was intended to execute the 
actial PEP microcomputer simulation software, and form the 
meelews of the project. 

The KAYPRO 10 hardware was intended to support two 
primary functions. First, it had to be capable of supporting 
the software development effort of the PEP simulation. 
Taeoudweet nad to be able to run the PEP application in an 
actual class room environment. The KAYPRO 10 hardware was 
able to support the PEP software development process much 
better than the prototype machine for two reasons: 1) the 
KAYPRO 10 represented a much more capable hardware 
SOU aenom than the prototype machine in terms of its 
weemirey tO provide an efficient interface to software 
Meetomment tools such as text editors, and other 
applications programs, and 2) many of the lessons that were 
Peeriredesusimes the prototype hardware were directly 
applicable to the new PEP hardware. 

The actual operational implementation of the KAYPRO 10 
hardWare, was scheduled to occur during the December, 1983 
(ieetemeime goal was to have the entire PEP software 
development completed by this time. The success of this 
implementation, and indeed the thesis project itself, hinged 


on the development team's ability to employ the second 
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meer phe of hardware implementation, getting the users 
Meeeved In tne process. The strategy that was adepted to 
insure this user involvement took place was to have the 
Reems) sroup actually write the User's Manual for the 
December MCPCC PEP demonstration. The user's group was 
provided with the documentation about the KAYPRO 10 hardware 
that was supplied by the vendor. Their task was to take this 
information and repackage it so that the MCPCC students 
would have adequate information to use the simulation. 
Having the user's group write the PEP User's Manual was 
considered an appropriate means to offset familiarity bias, 
Te weeeementation pitfall that the development team 
consciously sought to avoid. 

A survey was taken after the the December, 1983 MCPCC 
implementation of the PEP simulation to obtain the students 
evaluation of the hardware's effectiveness, and the manner 
in which it was implemented. In general, the results of the 
Survey were very favorable on both accounts, and indicated 
that the hardware implementation had gone very well. More 
detailed student evaluation results will be provided in a 


later chapter, which addresses all of the PEP project 


findings. 


H. MAINTENANCE 


This phase of the hardware lifecycle normally does not 


@etethe attention that it deserves, yet it can prove to be 
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one of the most expensive elements of a system's lifecycle 
costs. Maintenance can be defined as the process by which 
any degradation in hardware performance from variances in 
wees peciiications, to complete failure, are corrected 
meet eee pe. 196]. lt is certain that once hardware is put 
BmeQese@hvace, it will require varying degrees of maintenance 
Support over time. iMicmmoGmlyaanay fOr ak onganizakion to 
Pierre that it does not get caught by surprise when the 
mepaiGetruck shows up, or fails to show up, is to have a 
well planned hardware maintenance strategy in place that is 
preemptive vice reactive. The specific provisions of a 
Taeeeeomamece CONtract will vary from organization to 
organization, depending on how critical a role the hardware 
Peace the daily operations of the firn. In some 
industries, such as banking, computer down time that is 
caused by hardware problems can have a devastating impact on 
the organization, Millions of dollars can be held in queue 
as transactions go unprocessed. Organizations that rely on 
real time processing for their life blood should have a 
feaincewemee Contract that supports this type of operation. 
A computer manufacturer has even gone so far as to base 
Peet oeemrare business on the importance of hardware 
reliability and low maintenance requirements. Tandem 
Compmeer Ss market niche is that they sell computers which 


Paemeweremeiy reliable due to built in redundancy. Hence, 
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the equipment foageetre OF Clrrences Ehat will require Ma jor 
maintenance, and involve extended down time, are negligible. 
Many organizations have purchased Tandem computers because 
of these features. Other types of organizations, which rely 
primarily on batch processing to satisfy their ADP needs, 
may be able to tolerate nominal amounts of down time due to 
hardware failures. However, even when batch processing 
operations are involved, there must be some type formal 
agreement as to who is responsible for what type of 
ieeeemance 1.e€, preventive, corrective, at what echelon, 
and what constitutes an acceptable amount of down time 


before it begins to adversely affect the organization. 


I. MAINTENANCE - DEVELOPMENT TEAM ADAPTATION, 

The maintenance strategy formulated by the development 
team was to ensure that vendors who were awarded contracts 
would be capable of: (1) providing maintenance support 
beyond the AR ee standard equipment warranty, G2") 
ensure that a technical support facility was geographically 
close enough to resolve major or minor maintenance problems 
within twenty four hours, or (3) loaner equipment would be 
Bvedtlable for this contingency, and (4) that manufacturer 
promulgated revisions to the basic hardware would be 
provided by the vendor at no cost to the Government. The 
short run goal of this strategy was to minimize the risk of 


missing the designated December PEP implementation date due 
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to hardware related-delays. In the long run, it was designed 
Smee vOut protracted maintenance problems in future 
applications. 

There has been occasion to test the robustness of the 
maintenance provisions of the hardware support contract for 
both minor and major maintenance problems. The maintenance 
strategy appears to be sound, based on the development 
team's preliminary experience in this area. All problems 
that were encountered, subsequent to the receipt of the 
hardware, were resolved without incident. All maintenance 


work was completed within contract specified timeframes. 
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A. INTRODUCTION 

The purpose of this chapter is to demonstrate the 
integration of the simulation development lifecycle into 
this thesis. This demonstration will focus on the "How", 
not the "What". It is not intended to be a redundant 
discussion of the simulation development lifecycle. Rather, 
MEd escriptive narration of the creation and 
fevelbopment of the PEP microcomputer simulation. To 
structure this narrative, the chapter sections will commence 
with the simulation feasibility phase and proceed through 


the simulation maintenance phase. 


Memore ~ontinwing, it is appropriate to list the 
primary supporting documentation that was employed in this 
Simulation. This supporting documentation included: 


1. The PRIME Enhancement Project User's Manual (Draft 
Copy): Published by the PEP development team, this 
document provided the simulation development team with 
a comprehensive system summary, user operating 
procedures for data input and queries, and general 
background information on the parent system. 


2. The PRIME Enhancement Project Supervisor's Manual 
(Draft Copy): Also published by the PEP development 
team, it provided the simulation development team with 
a comprehensive summary of PEP's supervisor subsystem. 
Further discussion of this subsystem is presented in 


section C of this chapter, The Simulation Requirements 
ace pecasacations Phase. 
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3. United States Marine Corps Order 7300.10B, Mechanized 
Financial Procedures for Selected Marine Corps Posts 
sue otations: this document provided file, record and 
peewee riniébions for PRIME. aAs such, it was a ready- 
made data dictionary for use with the dBASE II command 
language. 

*. dBASE If Assembly Language Relational Database 
Management System: The user's manual for dBASE II, 
this document provided the development team with ea 


wealth of language-specific information. ite falc al 
Daodter: of Ashton Tate. 


pee He SLMULATION FEASIBILITY PHASE 

AS the name implies, this phase dealt with the 
mememevawbility of the simulation. From a managerial 
perspective, the feasibility analysis is viewable in three 
subsets: simulation feasibility, economic feasibility and 
cecmmical feasibility. 

Mmiewsamulation feasibility question is the focus of this 
thesis. As such, this feasibility subset will be addressed 
in chapter VIII, Conclusions and Recommendations. During 
the actual simulation development lifecycle, the simulation 
feasibility was assumed to be doable. Laas sass um pt 10n 
motivated research into the matter and propelled the 
Gemammader Of the simulation effort. , 

A high degree of overlap existed between the previously 
described software and hardware requirements (chapter IV and 
‘or Simeehes technical and economic feasibility. This 
relationship was compelled by the ability to define 


mandatory software and hardware requirements, and the 





subsequent identification of candidates that met the ¢cefined 
requirements. Mysomeonmnectionm= 10 plied the technical 
Meastpility of the simulation. “Further, thé integration of 
a mandatory cost ceiling into the requirements definition 
and the availability of candidates within the cost ceiling 
implied economic feasibility. In summary, the fact that 
there were candidates that conformed to the mandatory 
software and hardware requirements was interpreted by the 
project team as a positive technical and economic 
meas dpi lity . 

Normally, the macro definition of the parent system to 


Samiibateris done in the simulation feasibility phase. As 
Stelrnmed in chapter [JT1, the PRIME Enhancement Project was. 
designated as the parent system to simulate. 

A cost/benefit analysis is routinely accomplished in 
M@mebcmephase of the lifecycle. Mig S91 Jaya) jo ees) (=) (ele eee 
cost/benefit analysis was not formally performed. Rationale 
for this omission was: 

MElnemidct that a project sponsor was willing to commit 
financial resources to a research effort indicated a 
higher management decision that expected benefits 
Saeeecaed the anticipated costs. Relying on this 
barometer, the performance of a cost/benefit analysis 
was judged to be a redundant task. 

Zeeemcact that the project was driven by research 
objectives, vice concrete, quantifiable output 


measures, tended to make the performance of a 
cost/benefit analysis an amorphous exercise. 
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Pope Gcewree Jot financial resowrces committed were 
minimal, with respect te the perceived benefits at the 
project team and project sponsor level. 

Concluding the simulation feasibility phase, the project 
team conducted a schedule analysis and performed some 
preliminary project development. Often, these tasks are 
accomplished at later points in the simulation development 
Mitecycle. They were done at this point in this project to 
Minimize project risk by establishing milestones. The 
mteeames of the schedule analysis and preliminary project 


development were: 


Peet temrormatt Mon of the Ser eroup that served to 


menalize the project team composition. Further 
Gmisemss#on of this subject can be found inwchapter 
LT Te 


2. The August,1983 MCPCC was designated as the fieldin 
date for the prototype system. The December, 1983 
MCPCC was set as the implementation date for the 
Simulation. 


3. The user group EOumUtatea dA training scenario 
Demo lime around budgeting and an electronic 
spreadsheet. As this was outside the scope of the 
defined simulation, the user group assumed the 
Gomepmeste responsibility tor development and 
implementation of the package. 

eta eee MULATION REQUIREMENTSe AND SPECIFICATION PHASE 

The purpose of this phase was to designate the essential 
elements of the parent system that were to be present in 
the simulation. The software and hardware requirements were 


defined concurrently, and are presented in chapters IV and 


V, respectively. 





To designate what to draw out of the parent system, the 
project team conducted a comprehensive review of the PEP 
User's manual. This self-education process was followed by 
Melatarvsonevisit to the Accounting Office, Marine Corps Base, 
Camp Pendleton, California. At this site, the parent systen 
was operational on an Amdahl 470/V7 computer. Additionally, 
this visit allowed the simulation project team to interface 
with the PEP development team. 


The trip to Camp Pendleton produced the following 


meiguits: 

1. The PEP development team informed the simulation 
development team that another primary subsystem of PEP 
had been implemented. Known as the Supervisor 
Sosyvystem, tt had grown out of recent user requests 
and a surge development effort. <A piece of primary 
documentation, the PEP Supervisor manual, was 
obtained. 


2. Response times to interactive PEP users on the parent 
system were observed to be slow and cumbersome. The 
asieteneid operating system priority of PEP, and high 
proeessor utilization were discovered as the 
explanation of this slow response time. 


3. A complete source listing of PEP, written in NATURAL, 
was obtained. 


4. There was a general consensus among PEP users that PEP 
was preferred over the previous alternative, a 
SCANDATA product. 

Upenmercompletion of the liaison trip, the learning 
process of the simulation project team had advanced enough 
to allow an intelligent and meaningful definition of the 


simulation requirements and specifications. This effort 


produced the following: 
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The parent system emplovs interactive input to a batch 
transaction file. This feature of the parent systen 
would not be present in the simulation. Rather, the 
Saeevleeciem would employ the identical inswerective 
mipiiemode coupled with on-line file updating. This 
decision reflected the fact that the simulation was a 
mono-user system, and a batch file would be 
mappropraate for this specific environment. Also, 
i awie tile updating corresponded to the available 
user training periods. It was further felt that an 
on-line file update mode would avoid the slow response 
times observed on the parent system, and better hold 
the student's attention in a training environment. 


The following parent system input transactions and 
inquiry files were designated as essential elements to 
be present in the simulation: 


ces transactions: AD, AOMIL, AOCIV; AOMIL, 
A2CIV, BU, and RECAP. These transactions effect 
personnel records in the Personnel History File 
(PHF ). 


Deewe Mnguiry fides: The Unfilled Orders file (UFO), 
Reimbursable Order Number file (RON), Personnel 


History File (PHF), and Master Job Order Number 
fi Le cM ION = 


In the user group's opinion, these were the most 
Frequently used transactions and files in the parent 
Ssysten. VecucWw eet nev awowlLd be vital to the 
Simulation and tend to enhance the training process. 
The remaining transactions were not functionally 
developed by the development team due to time 
limitations, and with an eye toward future development 


Seton tits in other thesis projects. The omitted 
transactions would be physically present in the 
simulation, however, they would only be output screen 


FOonpmeaes and would not accept interactive inputs. 


The LOGON and LOGOFF procedures in the parent system 
would not be in the simulation. They contained a 
communications protocol, and non-English oriented 
prompts and responses. The LOGON and LOGOFF system in 
the simulation would be a simplified abstraction of 
the parent system designed to demonstrate security 
features and emphasize menu-driven responses. 
Additionally, the LOGOFF procedure would incorporate 
certain hardware-specific hard disk considerations. 
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wee weatsaction and inquiry screen formats and edit checks 


MerTemG@rawmwedirectly £rom the PEP User's manual. File 
definitions and structures were drawn from Marine 
Wompeecrder 7S00,10E. The underlying simulation data 


manipulation and processing was abstracted from 
development during this phase. It eventually became 
the responsibility of the development team, and tended 
Homemade tunetion of the dBASE Il command language. 


Seeeean initial effectiveness indicator, a user feedback 
survey, was planned and developed. 


6. It was formally decided that the Supervisor subsystem 
moneda he simulated emily in a text driven, screen 
fWermat., It would not accept user data input. Again, 
teas decdlisiom reflected thhe time limitations of the 
development team. Also, the Supervisor subsystem was 
an order of magnitude more complex, in programming and 
design terms, than the Input and Inquiry subsystems. 
Memecuci, dt would have required doubling of the 
development team personnel to implement. These 
resources were not readily available. Nor was it 
desirable to add to the project team at this phase in 
the simulation development lifecycle. 

At this point, the simulation requirements were placed 
Me eiesidocumentation file. This manual file provided a 


project team database to support documentation efforts. 


D. THE CONCEPTUAL SIMULATION DESIGN PHASE 

This phase was concurrent with the previously discussed 
hardware and software acquisition processes. The first step 
in this phase was the development of a fundamental model of 
PEP. Appendix C contains this model. User data entry is 
Pucewonuummcectree OL input. Thi¥s was drivem by the previous 
requirement for an interactive environment. Four possible 
outcomes, corresponding to the different simulation states, 


were f@rmner identified. lmesadisermete simulation states 


exe: 





reflected the requirement for a menu-driven system. This 
model was reviewed by the user group. They concurred with 
mes Content. 


Progressing to a more defined stage, a hierarchical 
process diagram was developed. It is portrayed in Appendix 


Ee Pinetionmaliy dividing the diagram into modules, the 


following modules were conceptualized: 


Weeversttaster Gontrol Module: This module was the 
operating system and database management interface 
with the hardware, contained the LOGON and LOGOFF 
modules, served to implement security features and 
performed system state determination. 


2. The Input Transaction Subsystem: This subsystem is a 
menu-driven module designed to permit a simulation 
user to input transactions. It has a direct interface 
with the database monitor to perform interactive edit 
checking of input data. Likewise, the interface with 

: the database monitor is the link to the on-line 
updating of databases. The subsystem has an internal 
hierarchy of different transaction types. 


Seeeevme lmauiry Subsystem: This subsystem is a menu 
driven module that allows a simulation user to 
designate the desired file and file view. The 
interface with the database monitor accesses the 
database and executes the desired query. The file 
View is definable to the field level, and includes 
aggregate and individual record views. 


4. The Supervisor Subsystem: This subsystem is a menu 
driven module that permits supervision of the Input 
and Inquiry transaction subsystems. It interfaces 
with the database monitor to achieve this supervision. 
Inherent in this subsystem is the ability to adjust 
simulation edit checks and error trapping defaults. 


>. The Unexpected Events Handler: This module operates 
at the system level. It includes the peripheral surge 


Protector, the hardware reset button, file 
Marae ation routines and a hard disk ‘crash 
Daooting routine. Pemtcm@estened to counter the 


Houmale realm of calamity. 
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The Database Monitor: This module is the simulation 
kernel. It contains the database management systen, 
and serves as the coordinator of the entire simulation 
execution. twee crpLeton data Input, Manipulate s 
databases, interprets and causes program execution, 
and performs simulation housekeeping. 


The Edit Validation Database: This module implements 
BCpeemeciecKang Olethe data inputs to the Input 
Deaiscaction subsystem. Database structure is drawn 
from the PEP User's manual. 


imcmeenquiry Validation Database: This module 
implements error trapping on the Inquiry Transaction 
subsystem. Database structure is taken from the PEP 
User's manual. 


iimemempervisor Validatiom Database: This module is 
Mime eCLEor detection device for the Supervisor 
subsystem. Database structure is drawn directly from 
the PEP Supervisor's manual. 


teomaterarchical process diagram provided a solid 


foundation for prototype development. Using the KAYPRO II 


hardware, the prototype was demonstrated on schedule at the 


August, 1983 MCPCC. The prototype demonstration surfaced 


the following: 


1 


The development team was made aware of an open file 
limitation of dBASE II. Also, the development team 
recognized a recursive call programming problem. 
While problems are never desired, this situation was a 
blessing in disguise. It made the development team 
rethink some of the fundamental program interface and 
calling methods. This change, made apparent by the 
prototype demonstration, caused the development team 
to save a significant amount of time and frustration 
in the detailed simulation design phase and in the 
Simulation module creation phase. 


The prototype concretely demonstrated the need for the 
Rei PRO 10 due to access speeds, and floppy diskette 
Storage Wimits. 
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Ming this phase, the user group was forzally 
designated as responsible for the preparation and 
development of the simulation user's manual. Coupling the 


meweeeto the simulation in this manner produced stronger 


Besting, and a more understandable, easier to follow 
simulation user's manual. 

The phase concluded with a management review of the 
project. Requirements validation and milestone evaluation 
were included in the review. Detailed transaction module 
schedules and testing periods were identified. Tighter 
controls were applied as the project drew closer to the 


implementation deadline. 


ie | 6 PDH DETAILED SIMULATION DESIGN PHASE 

This phase began with further decomposition of the 
Miemaisenical process diagram. This decomposition produced 
morvedtal program modules, These individual program 
modules were defined from the following parameters: 

1. The User's perspective: The screen format. 

2. Data Structure and Databases: Reflective of the PEP 
User's manual (edit checks and error trapping), and 
Varame Corps Order /7300.10B. 

Seemmeeriaece Relationships: Designation of senior- 
subordinate module relationships, module calling and 


tapceetow to and from the module. 


4. Module Purpose: Pinecetomalemcpecirication of the 
module's primary task(s). 


icmiiewcqdmepreakdowne of Ehe above as contained in the PEP 
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PeenOcompuEter Simulation Systems Reference Manual, which is 


ct 


discussed later in this chapter. Appendix E contains a 


tf) 


Summary of this decomposition by subsystem and program 
module. 

iiwecmpiase covemed everything short of actwal program 
coding. It was a time intensive process, and served to 
demonstrate to the development team the critical need for 


planning in the simulation development lifecycle. 


F. THE SIMULATION MODULE CREATION PHASE 

This phase involved taking the products of the detailed 
simulation design phase, and transforming them into dBASE II 
command files. These command files contain the executable 
Geese Ll statements that breath life into the simulation. 
The time and effort invested in the detailed simulation 
design phase was well spent as the transformation process 
Seveetairly smoothly. This was also awreflection of the 
Sonyeemelish-like functions in dBASE II. 

Faced with limited personnel resources, the two members 
of the development team became specialists. One member 
aeoumed sane respemsibility for coding the edit-intensive 
GPepat Toemisaction subsystem. The other took on the 
epee lemeewot the Master Control module and the Inquiry 
Transaction subsystem. 

Throughout this phase, the development team relied on 


the following programming support resources: 
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1. WordStar Word Processing System: Thi saacro Pro 
product was employed as a text editor. PWS Oe 
allowed command file execution directly from the text 
editor environment. 


2. The dBASE II User's Manual: This voluminous manual is 
often criticized for its complexity. The development 
team found it to be a useful and understandable 
document. However, they felt it was intended for use 
by at least moderately experienced programmers. 

3. The KAYPRO 10 microcomputer: The integral 10 MB hard 
disk, coupled with WordStar, provided a superlative 
development and debugging bed. 

[eeewcouwe dot Matrix printers: Their speed and output 
readability were essential to program development. 
Also, they enhanced the documentation effort. 

In addition to command file development, the development 
team created the requisite databases and initialized the 
database records. This process was interfaced with the user 
group tutorial development effort to ensure system 
consistency. 

Realizing that programs written by others are frequently 
difficult to understand, the development team applied 
documentation standards to the command files. Each command 
mien nad a header with the following entries: 

I. File purpose. 

2. Parameters passed to the file. 

3. Parameters passed from the file and where to. 

eernnor checking . 

Siamormammers . 


6. Date the file was last updated. 


Within the program, each major function was highlighted with 
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a descriptive comment, and appropriately Spaced to 
Seeneate the function. The command files were reviewed by 
the user group foe understandabilityggsand suggested 
documentation improvements. 

Unit testing, which receives an in-depth discussion in 
the next chapter, was performed in this phase. After a 
development team member produced a 'debugged' program, it 
was presented to the user group for a 'road test’. This 
peocecure e€nhanced the user group interface with the 
simulation. It also removed the program from the author, 
who could have been unconsciously avoiding invoking program 
errors. The entire process provided good feedback, and 
served to establish a near real time verification and 


validation cycle. 


G. THE SIMULATION MODULE INTEGRATION PHASE 

Upon completion of unit testing, the program modules 
were integrated into the Serie ion, THES was concurrent 
with the previous simulation development lifecycle phase. 
Interface testing and variable passing were examined in this 
immeEe gration. Also, this phase served to validate error 
trapping and edit checking performed by the databases 
across the system. The objective of this phase was a 
Validation/verification/refinement cycle, coupled with a 


weeecmomdane doctlmentation updating. The reader is 
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ieeected to chapter Vii for a detailed description of this 
process. 

The next phase was the acid test: implementation. To 
prevent any surprises, a management review was held at the 
conclusion of the simulation module integration phase. 
Mmomsistency of the tutorial and the simulation were 


stressed. Also, the milestone attainment was examined. 


H. THE SIMULATION IMPLEMENTATION PHASE 
Piemcimulation was tielded at the December, 1983 MCPCC. 
It included the following: 
!. One hour of in-class familarization and system 
overview. Tutorials were distributed to the students. 
The objective of this session was to introduce the 


students to the simulation and its equipment, and to 
Minimize student resistance to computer use. 


feeivemaotudents each took a KAYPRO 10 to their quarters 
wrer. class hours. Here, they worked through the 
tutorial. The event provided good informal feedback 
on the simulation to the project team. 

3. Upon completion of the MCPCC, the user feedback survey 
was administered. The results are discussed in 
chapter VII. 

Redundancy was the key to the simulation backup 
strategy. The strategy consisted of the following layers of 
backup: 


1. Primary Data Location: User area AQ, KAYPRO 10 hard 
disk. 


2. Secondary Data Location: Floppy diskettes held by the 
development team. 


Seeeleremary Vata Location: NPS computer center, under 
Weemescentiftication number OZ50P. 


rz 


ee emery Vata Location: Hard copy printout held by 
the thesis advisor and the second reader. 


meen eae 100e fault proof, this strategy is capatie of 
preventing most data loss catastrophes. 
The development team's documentation, the ie Jee Ie 


Microcomputer Simulation System Reference Manual, was 
developed from the project documentation file. In addition 
to a complete listing of command files, the following areas 
are contained in the manual: 
1. Overall System Configuration. 
@. System Hardware Configuration. 
3. System Software Configuration. 
a. Commercial software. 
b. Development Team Software. 
i. 7! Pee, 
aa The speadsheet scenario. 
4. System Backup. 
Permanent distribution of this document was to the thesis 
advisor and second reader. This distribution is intended to 
permit intelligent future development of the simulation, 


based on a solid presentation of previous development 


Smeoresceand technical information. 


This phase concluded with the user group refining the 
Slat Tom user's Mantial on the basis of the user feedback 


survey. 
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2% 
Bye 


THE SIMULATION MAINTENANCE PHASE 


Currently, the primary components of this phase are: 


Use of software utilities e.g. FINDBAD for minor 
hardware preventive maintenance. 


Tnereased sovirce code documentation. 


[eae erensimikeriace with the vendor f£or hardware 
GOnrrective maintenance. 


The future maintenance strategy will be a direct function of 


the 


development path pursued with this simulation. 


Alternative development paths are discussed in chapter VIII. 
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A. INTRODUCTION 


Mimeomciapter will present the topic of test and 
evaluation. olcmeaGn mM Gmesceedem tal part or the system 
development process as it typically determines how expensive 
system maintenance will be. Research data indicates that 
System maintenance costs have historically represented the 
Mingest portion of a system's lifecycle costs [Ref: 11: 
pels |. 

This chapter will be developed in accordance with the 
underlying structure of this thesis. First the principles 
of test and evaluation will be discussed. These principles 
mae et ormal and informal testing procedures, (2) the 
relationship of requirement specifications to testing and 
Quality assurance, (3) quality characteristics, (4) quality 
Meermres. (5) automated test and evaluation tools, and (6) 
the life-cycle implications of testing and evaluation. 
Secondly, the development team's implementation of these 
test and evaluation principles will be discussed in the 


context of tangible application results. 


B. BACKGROUND 
Dror e to studying an abstract topic, it is useful to 


define the key terms and concepts that are germane to the 
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topic. This procedure was applied to the topic of test and 
evaluation. This ensured that frequently used words were 
clearly defined, relative to the topic. 

The point of entry for the identification of terms can 
Pegemewith the subject title itself, “test and evaluation”. 
These two words are frequently used together to represent a 
single evolution. Although these words are similar, they 
should actually be decomposed into separate pieces to 
describe the actual processes that occur. System testing 
@eyconcerned with the reliability of a given set of hardware 
and software, respective to a given application. The word 
eaetaability", as it is used in the preceding statement, 
refers to three characteristics: [Ref. 19: p. 3-14] 

eerecuracy of computed results. 
2. Compliance with system specifications. 
3. Robustness. 

Mak@acion is concerned with how much, or to what 
degree, a system satisfies some pre-determined set of ideal 
performance measures [Ref. 19: p. xi]. Thus, the evaluation 
process permits a system to be judged, and perhaps ranked, 
on its ability to satisfy the application requirements. The 
Mimmilarity between test and evaluation is that both 
processes are used to document a system's performance and 
behavior. The primary difference between the two processes 


is that testing is concerned more with the details of system 
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eommeemmess and iS more specific than evaluation, Evaluation 
typically considers more aspects of system performance other 
than simply system reliability. 

Testing and evaluation Gan be conducted at different 
levels within a system hierarchy. There are two basic 
levels: the systems level and the component level. Ror 
eau, i is important to specify which level is being 
referenced. Test and evaluation criteria at the component 
Wewel will be oriented toward a more detailed perspective 
than at the system level. Although individual components 
usually are integrated to make a complete system, the test 
and evaluation criteria and procedures that are used at each 
level can be quite different. Ps Ss li Ge Me Sates, olka 
encompass both levels and will be explicitly differentiated 


when appropriate. 


C. FORMAL AND INFORMAL TESTING PROCEDURES 

The primary objective of any system developer is to 
create a "quality" end product in terms of both hardware and 
software. This section will examine the characteristics 
which define software "quality". Research indicates that it 
fevembeemuparticularly difficult to measure the quality of 
fPormauarewmam a working system [Ref. 19: p. xvi]. This 
problem is no small matter as software has been shown to be 
RiemiG@eminawrte cost factor in the lifecycle of most major 


epieemo tReft Ll: p. 30 - 32). 
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Mee PEP simulation development team recognizec how 
important software quality would be to the success of the 
Bro ject and en femur ated a test and evaluation 
strategy that would support the design of quality software. 
The first issue of the test and evaluation strategy that had 
to be resolved was to determine what type of testing method 
to use: formal or informal? Formal testing was found to be 
most appropriate for situations where the scope of software 
complexity was low to moderate [Ref. 20: p. 80]. Formal 
testing procedures are used to establish the mathematical 
proof of correctness of an algorithm in accordance with some 
Meewmouely defined set of specifications. Formal testing is 
mapeeatty oniy used in conjunction with small software 
Modules. Rationale for this is that as the size of the 
software increases, so does the complexity of the procedures 
that are used to establish its proof of correctness [Ref 20: 
pee oy. Ihe complexity of formal testing can be driven to 
the point where it is no longer feasible to conduct such 
testing. This is due to the current lack of automated tools 
Poeperform tormal testing, and the fact that the testing 
methodology itself may contain errors if the procedures that 
are used become too complicated. 

The PEP microcomputer simulation was reviewed to 
determine to what degree formal testing would contribute to 


achieving the objective of producing reliable software. As 
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Peeper: Of this review, it was determined that formal 
Mestams was not well suited for this particular application. 
Mext, the alternative method of informal testing was then 
examined for its suitability with respect to software 
wecotime wand reliability. 

Informal testing was found to be synonymous with the 
conventional notions of software testing such as debugging 
Member iace input/output checks. Informal testing is 
molltinmely used in situations where complex systems are 
involved, or where a large number of integrated modules must 
Demspeated (Ref. 20: p. 80]. Informal testing is used in 
these cases because there are automated tools available that 
Can assist with the testing process, and the test itself is 
Peas eraeorous a proof as in the case of formal testing. 
On this basis, the PEP microcomputer development team 
decided that informal testing was the best method to use for 
the software reliability analysis. 

Tt should be stressed that informal testing is not to be 
Somemsedswith imprecise testing or inaccurate testing. In 
fact, informal testing can be considered quite "formal" in 
BaemGonbektmot precision when it is used in conjunction with 
software reliability design enhancements such as-7~ structured 
programming, mos. | ame, Aide eon cy eeespieci fication 


requirements. The relationship of these design concepts to 
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Meeenumal testing will be explored in ereater detail in this 
chapter. 

iesmoudd be noted that) the choice to use informal 
testing, as opposed to formal or piecemeal testing, was made 
momeemerease the probability that the delivered PEP 
simulation software would be reliable. Even if software is 
exiaustively tested it cannot be considered 100% “error 
free’. This is because testing only proves the presence of 
errors, if can not prove their absence [Ref. 20: p. 76}. A 
vendor's claim that a given software product is completely 
without bugs because it successfully passed a testing 
procedure should be considered wishful thinking. 

The testing process should be structurally supported 
from the outset of system development by an appropriate 
mesimm structure. The PEP microcomputer simulation 
development team considered two software testing structures: 
"top-down" and "bottom-up". The decision to use one design 
alternative over the other was governed by how well each of 
the respective alternatives would support follow-on testing. 
The top-down design method was found to be the generally 
better approach. Top-down design permits system testing on 
an ‘as you go' basis, because higher level modules are 
developed and tested before lower level modules. Also, it 
is not necessary to have all the lower level modules 


completed prior to higher level module testing. Calls to 
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epeomplete lower level modules are replaced 5y progran 
stubs. Using this technique, interface output parameters of 
the higher level modules can be tested for accuracy. 
Bottom-up testing relies on the lower level modules being 
developed first. These individual modules are tested and 
then integrated into the overall system. The major problem 
with bottom-up testing is that the module integration phase 
P—treduently rotgh and choppy [Ref. 18: p. 159]. Also, 
even though individual modules can be tested, it is 
[eeercult to test the system as an entity until all the 
subordinate modules have been completed and integrated into 
the system. At that point, if program bugs are encountered 
(usually at module interfaces), they are very difficult and 
mememweostly to correct. 

An added benefit of using the top-down design approach 
was testing by the users early in the simulation 
development lifecycle. The nature of top-down design 
Teel y required construction of a complete skeleton of 
the PEP system. This was the master control module (chapter 
VI) in the hierarchy, and it controlled the flow of control 
to all the subordinate modules. This permitted the users to 
test the working PEP skeleton for errors, despite the Pairs 
that none of the lower level modules had been developed. 

Getting the users involved in the testing process at 


such an early stage in the software development was 
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mmvarteabie to the overall success of the prejecs. fhe 
combination of top-down design and user involvement in the 
testing process yielded numerous benefits. It set the stage 
for future module testing, the users felt as if they had a 
vested interest in the software design, and most 
importantly, system design and development errors were 
isolated early enough to take corrective action without much 
ieee culty. An example of this testing methodology's 
utility was evidenced when the users requested that a change 
be made to the PEP skeleton. The requested change modified a 
module calling sequence from the design specifications. It 
Meme fected without difficulty primarily because the 
actual interfaces of the lower modules that would have been 
effected by this change were not yet in place. Had these 
modules been integrated into the PEP system before the 
requested change was made, it would have been significantly 
more difficult to make the desired change. This ‘test as 
you go’ procedure with the users group was was used 
throughout the remainder of the PEP simulation development 


ierecycle. 


Pec eOUMREMENTS SPECIFICATIONS, TESTING AND QUALITY ASSURANCE 
In order to perform any type of testing there must be a 

set of criteria that is available as a test standard. These 

test criteria are frequently referred to as requirements 


specifications. These specifications, whether at the 
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systems level or the component level, should provide a clear 
statement of what the software is intended to do. At the 
Somponment or unit level, requirement specifications often 
state test boundary ranges, input/output parameter values, 
and module interface consistency. They tend to be 


Mrentitied in significantly more detail than requirement 


specifications at the system level. 

As described above, each module was developed in a top- 
down hierarchical precedence. After each module had been 
developed, the following tests were performed: 


1. It was tested for data accuracy if computations were 
involved. 


Peeevota input/output validity. 


SeeeGompliance with requirement specifications, both 
formal and informal. 


4. Robustness. 
The testing process was accomplished on a completely manual 
bacawseeemetensive error handling routines were built into 
modules that were vulnerable to erroneous input conditions 
or system states. Robustness of individual modules and the 
system was a primary design consideration. It reflected the 
the diverse nature of the group that would be using the 
system. Robustness was tested in two ways. Known error 
conditions would be introduced into the module to test and 
exercise its error handling capabilities. The second method 


was to pass development team debugged modules to the users 
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Mmm robUuStness froad test. ' 


Experience with this 
Beenma que showed that if it were possible for an error 
condition to be produced, the users would find a way to make 
ft hasp p em. i pecs e pon dadieidename wer y effective means of 
identifying where error handling routines needed 
Bematorcement, and where to put self checking input edit 
routines. Input edit routines were used extensively as a 
method of achieving enhanced robustness. 

The degree of formality of the testing methodology is 
directly influenced by the formality of the requirements 
Emecitacations [Ref, 19; p. xxix]. These specifications can 
range from simple verbal instructions to formal automated 
requirements definitions. The degree of formality usually 
Mirrors the size and complexity of the software development 
BiGsOr) eC t.. Wigwne Celopect@aemo testing, requirements 
emeecri1cations provide a point of reference that can be used 
PmeEd@emermimne if a system is being built correctly. A 
typical problem that is encountered with software 
requirement specifications is their oftentime ambiguity in 
terms of precisely defining what the software is supposed to 
aloe Recent developments in the automation of software 
requirements definition have greatly enhanced the testing 
process by alleviating much of the ambiguity problem [Ref. 
eos | however, these automated tools are normally 


economical only when used to support large and complex 
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software development projects. Semi-structured, written 
pee lish requirement specifications are still widely used fer 
projects of small to moderate complexity. The problem with 
Mes iish language requirement specifications is that their 
Bendency toward ambiguity. It should be apparent that the 
testing process is adversely affected by the ambiguity that 
can result when common English statements are used to 
describe requirement specifications. The reason that formal 
automated requirement specification techniques are not used 
to support small and moderate projects is due to the 
processing and personnel overhead costs associated with 
Such methods. 

iteebcepenvVisioned that the cost of these types of 
programs will decrease as their use becomes more widespread. 
More detailed information about these formal requirement 
specification language methods will be provided in a latter 
section of this chapter. 

The primary documents used to define the requirement 
specifications of the PEP simulation were considered formal 
in the sense that the displays and figures were reasonably 
mmecmece am their definition of what the parent system's 
purpose, The ambiguity problem was manifest when the users 
attempted to state their requirements verbally using the 
English language. One of the PEP simulation original scope 


constraints was the entire PEP parent system could not and 
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would not be emulated in the timeframe alloted for the 
project. The users group was responsible for identifying 
Mmemexact bounds of this scope constraint. They were to 
develop a clear and concise statement of system requirement 
specifications, reflective of any deviations from the actual 
mee User's manual. The user's group requirements 
feeetatecations were imprecise, difficult to follow, and 
difficult to test against. This situation should be avoided 
at all costs. The problem was eventually solved by using an 
lterative requirement specification refinement process 
between the PEP simulation development team and the users 


group until an acceptable set of requirement specifications 


was produced. 


E. CHARACTERISTICS OF QUALITY SOFTWARE 
The predominate share of the preceding discussion on 

software quality has been presented in terms of software 
Pelieapility. This is certainly an important characteristic 
of software quality. However, it is not the only attribute. 
Research has indicated that the quality of a particular 
software product can be described in terms of the following 
Guemommt cheracteristics: [Ref. 19: 9p. xi] 

1. Understandability 

2. Completeness 

3. Conciseness 


fe Porcabality 


Loe, 





5. Consistency 

oe Maintainability 

ieee testability 

Eeeeelsability 

cee eliability 

10, Structuredness 

mimey orriciency 
The relative importance of each of these attributes is 
Mimetion of user requirement specifications and the 
pecation. 

The PEP simulation team took conscious measures to 
Smeeimre that each of the above quality characteristics was 
incorporated into the structure of the system design. The 
criteria used in the software evaluation matrix provide a 
tangible example of this deliberate software quality design 
Serort. Mnemcatdonale for Wsame a particular software 
evaluation criteria was based on the attributes of software 
G@iality that were identified above. The decision to use 
dBASE II as the implementation language for the PEP 
simulation reflected the development team's concern for 
quality software production. dBASE II readily supported 
modern software design principles like structured 
DPaogmammmne, top-down design, modtlarity, and self 
cocumemtation. These qualities were exploited in the 


detailed design and module creation phases of the PEP 
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simulation development lifecycle with one singular 


meme tne production of a quality product, 


mee BCUALITY "METRICS 

The term "metric" is defined as a measure of the extent 
or degree to which a product possesses and exhibits certain 
Silamaeeeristics [Ref. 19: p. xv]. The focus of this chapter 
mace DeEemM On the quality characteristics of software. 
However, the scope of the discussion need not be restricted 
MoOmmemls Narrow context. It is the user who ultimately 
determines what set of attributes should be present for a 
Peeoemtct: to be considered a “quality” product. Once these 
attributes have been defined, quantifiable metrics can be 
developed to evaluate the degree to, which a given 
Piteagekeristic is present. Theoretically, if the chosen 
characteristics accurately represent the quality of a 
peoauct and the metrics determine to what extent these 
@m@aracteristics are present, then a high correlation between 
Brcmemaracteristic and the metric should indicate that a 
product is indeed a "quality" piece of work. The method 
used by the PEP simulation development team to evaluate the 
software quality in the simulation system will be discussed 


Mima separate section of this chapter. 


G. AUTOMATED TOOLS THAT AID TESTING AND EVALUATION 


System and software design is an abstract process which 
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mmvouves the transforMation of creative ideas into concrete 
requirement specifications. Ambiguity is often generated as 
an unwanted by-product of the transformation process due to 
wre manner in which humans deal with complexity. As 
Peeeviowsly stated, ambiguity, in terms of requirement 
meecttications, seriously impairs the process of system 
Sorte. Based on this realization, it is apparent that a 
memcrwsexists for design tools which can help humans 
automatically define precise requirement specifications from 
abstract ideas. Such automated design tools have recently 
been developed which are intended to accomplish this 
objective. 

Automated support tools were developed primarily to 
satisfy the software design and implementation needs of 
major system projects. The complexity of these systems, 
measured in terms of requirement specification volume, 
Simpy became too difficult to manage using conventional 
verification and testing techniques. The Ballistic Missile 
Defense (BMD) system is an example that is often used to 
illustrate this phenomenon. The Defense and Space Systems 
GCeompmot the TRW Corporation was responsible for the BMD 
project development. The requirements document for the BM D 


Syceme is @e0omprised of no less than 8248 individual 


roquarement and support paragraphs, and is contained in a 


2,500 page specification document [Ref. 20: p. 160]. TRW's 
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solution to this management nightmare resulted in the 
creation of an automated software design support tool called 
SREM (Software Requirements Engineering Methodology). The 
purpose of SKREM was to allow the system designer to state 
requirements in a reasonable natural language and then use 
automated techniques to handle the details of keeping track 
Soemcmanges, ensuring consistency, and reporting the 
Tterative effects of statements [Ref. 20: p. 160]. A 
aeeotal requirement specification language and database 
model processor were developed to implement SREM. The 
special language was called Requirements Statement Language 
ers lk) Mime lantieuage used precise syntax to detine 
re@@irement specifications. The use of this syntax 
accomplished two things. First, it helped alleviate the 
Boagurmement specification ambiguity problem. Second, it 
allowed a regular interface to permit computer processing of 
RSL defined requirement specifications. The Abstract System 
Semantic Model (ASSM) is a relational data base that is used 
to store RSL defined specifications. This data base is an 
integral part of the SREM system. The actual application 
Programs used in the SREM system to perform requirement 
specification management use the ASSM for data retrieval and 
file storage. 

Other types of automatic design tools have been 


developed which take a slightly different approach than 
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SREM. SADT (Structured Analysis and Design Technique) was 
eeeeoe developed to help designers write clear and precise 
requirement specifications and automatically perform data 
Baise Oriented howse keeping functions. The primary 
Meret ence between SADT and SREM is that SADT makes 
Pweemoarve use of graphics to describe the interaction of 
system modules and requirement specifications. Problem 
Statement Language/Problem Statement Analyzer (PSL/PSA) is 


another example of an automated requirement specification 


Management tool. 

Although there may be slight implementation differences 
between different automated tool types, the more important 
issue to consider is what are the common characteristics of 
the automated tools. These common denominators are: 

Mmmesmmowlarity of purpose. 


2. Structured syntax for requirement specification 
language definition. 


3. Routines to translate tool defined requirement 
specifications into a computer processable format. 


“amciictam) Gata bases to store information. 


5. Application programs which manipulate the data that is 
contained in the data bases. 


6. A function oriented user interface i.e (graphical, 
Paeeoriented or a combination of both). 


The PEP simulation development team did not use an 
REOmainme Genre quinurement specification tool in the system 


design or test phase for three primary reasons: 


144 





I. Neo such tools were available at NPS either on the 
mainframe or the VAX minicomputer. 


Peo eh tOots do not currently exist for use on 
microcomputers. 


3. The scope of the simulation was not considered complex 
meme to warrant the use of these types of tools even 
if they had been available. 

The rationale for the preceding in depth discussion of 
automated tools was to demonstrate that even though an 
automated requirement specification methodology was not used 
herein, the conceptual foundation of these tools is relevant 


to any system design project. As such, their use should be a 


decision point when a system design strategy is formulated. 


H. LIFECYCLE IMPLICATIONS OF TESTING AND EVALUATION 

This chapter has examined many of the principles that 
are involved with testing and evaluation. The unanswered 
question at this point in the discussion is to what extent 
does testing and evaluation influence the success or failure 
of a systems design project over its lifecycle? The answer 
Bemmenass question should provide some insight into the 
rationale of why a separate thesis chapter was devoted to 
fois topic, 

lestrwme and evaluation are used for two primary 
pumposes: 


Mmemvomuogeument system performance in accordance 
requirement specifications. 


waeeeseba sh the framework for follow-on system 
maintenance. 
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These functions are critical to a successful implementation 
of a system design project. System documentation of test 
and evaluation results has historically been abysmal [Ref. 
mee p. 146]. System designers have typically viewed 
documentation as a necessary evil, rather than a useful 
Peterence instrument. As a result of this prevailing 
attitude, test and evaluation documentation is either: 


a mee produced at all. 


ap @erived in a haphazard manner as a secondary 
G@onsideration after the fact; or 


oe Memeeescribed in sufficient detail to be of any real 
use. 


Test and evaluation documentation is frequently treated as 
the stepchild of system development because it does not 
provide the immediate results, and hence gratification, to 
system designers that working code does. However, it is 
this type of documentation that can be of invaluable 
assistance in the debugging process and system maintenance. 

It is the system maintenance aspect of test and 
evaluation documentation that is really critical. It is 
Peeelaiby impossible to make systematic corrections or 
modifications to a system without the proper documentation. 
Test and evaluation documentation provide module interface 
information and system test results. This allows system 
modifications to be made in a rational manner. [It is also 


provided so reasonable predictions can be made about the 
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system's future behavior after the modifications have been 
made. Given the proportion of system maintenance cost to 
Mmmem rest Of the life-cycle cost, test and evaluation 
documentation should be assigned top priority in any major 
System design project. ine « test. cand ‘eva Puation 
documentation procedures employed by the PEP simulation 


development team are identified in the following section. 


ieee or OfMULATION TEST AND EVALUATION RESULTS 

Preset Er simulation development team decided to use a 
maiti-faceted strategy for testing and evaluation. The 
strategy is described as follows: 


1. Software testing will be initially segregated from the 
Deoe@ess Of evaluation. 


ee oiware testing will be done initially at the 
component or unit level. 


3. Informal testing methodology will be used. 


[tines rer User's Manual (Dratt Copy), and user group 
Powe witl define the domain of requirement 
Speci ileations. 


>. These requirement specifications will be used as the 
Somteware test criteria. 


6. Individual system modules will be tested in accordance 
with the above procedures. 


eee kodgeevidual modules will be integrated into a 


comprehensive working system i.e the PEP simulation 
project. 


8. The testing process will be merged with the evaluation 
process. The scope of testing will transition from 
details of component level to general system level. 
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. Users evaluate the system using predefined systen 
quality metrics. 


FO". Users evaluations and the software are the test and 
Svattatilomedoctimentation. 


The above test and evaluation strategy was considered 
successful as it provided structure and performance 
definition to the entire process. 

As individual modules were completed they were tested 
by two groups, the development team and the users group. 
These modules were compared with the appropriate set of 
Boamemement specifications to ensure that such things as 
screen formats, computed results, and input data were 
mimmeemented in accordance with the functional 
emeetiications. This process was conducted iteratively 
Dmemnany discovered discrepancies had been corrected. A 
master file was used to store and identify the most current 
versions of modified system modules. 

iivemunmtecration of the individual modules into the 
complete system was extremely easy due to the 
characteristics of top-down design. System integration was 
essentially an on going process as the higher level modules 
were developed and tested before the lower level modules. 
Completion of the system integration process allowed the 
transition to be made from software testing at the component 
level, to testing and evaluation at a higher and more 


femeral system level. This transition represented an 


148 





important phase of the test and evaluation process. This 
mmoreance was due to the decision that, while the final 
mem10n8of the PEP simulation certainly could not have been 
Completed without detailed module testing, the results of 
testing and evaluation at the systems level would provide a 
better barometer of how well the end product had actually 
been designed and built. This decision was predicated on 
Bre fect that users of the PEP simulation would not be 
concerned with the details of how the system was put 
together or functioned. Their primary interest would be how 
the system performed as an integrated entity. It was also 
meremge@ @nhat, since the PEP simulation was built for the 
Users, the users should determine the "quality" of the end 
PEocuet . This decision was considered consistent with the 
principle of information hiding as the development team 
dealt with the testing details of module interaction. The 
users' responsibility for testing and evaluation would only 
be concerned with those aspects of the PEP simulation at the 
system level. 

The concept of quality metrics was introduced at this 
point in the test and evaluation phase. The PEP development 
Eelateciiahe lhogically tailored these metrics to the system 
level evaluation. These metrics were chosen to evaluate 
more than just software. Although this certainly was a 


major consideration, they were also designed to evaluate 
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Maneware and system documentation. These metrics were 


Mieomperated into a gGuestionnaire format so that users cou 


}- 
am 3 


make subjective appraisals on the extent thet certain systen 
Mtiataty cllaractéristic were or were not present in the 
Boemerme Version of the PEP simulation. The questionnaire 
Seoemeconstructed in two parts. The first part was designed 
momovtain background information about the characteristics 
Seesene user group. The second part was intended to 
translate the opinions of the users’ group, with respect to 
PyVecemeqwality, into quantifiable results. This translation 
was implemented by constructing a low to high evaluation 
Semmme fOr each selected quality metric. A high score 
indicated that the user felt a high degree of the quality 
attribute was present. Conversely, a low score would 
indicate that the system lacked this particular measure of 
quality. The user group background data was obtained to 
[emp expiain the results of survey findings. The 
interpreted results of the survey were compiled to document 
Btewtest and €valuation findings. This documentation was 
intended to be used as the reference source ae system 
Maintenance and future project enhancements. 

An example of the questionnaire that was used is 
provided in Appendix F. The development team analyzed the 
Survey results and drew the following conclusions: 


1. The software and hardware performed in accordance with 
iecmone specifications. 
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meoyseem documentation, in the form of the PEP 


r 
ot Ww o~ —_ 


Srmuuvlatien Users manual, was well written and useful 
in terms of system operation. 


3. The PEP simulation provided a reasonable degree of 
correlation with the actual PEP system. 


cers Considered their participation in the PEP 
Simulation implementation to be a valuable learning 
experience. 

5. Adequate feedback information was obtained from the 
users, in the form of recommended changes to the PEP 
Simulation, to make future revisions to the current 
system. 

The test and evaluation phase of the PEP simulation was 
considered successful in terms of detailed component level 
testing and system testing. The development of a detailed 
test and and evaluation strategy early in the design of the 
PEP simulation life-cycle was considered an essential part 
eee ts successful implementation. Mnemitces OL Gualat y 
HetGles and the other principles of testing and evaluation 


presented in this chapter were also considered to be 


Mipertant parts of the system design effort. 
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VIII. CONCLUSIONS AND RECOMMENDATIONS 


ee. Ln lTRODUCTION 


mircmeirapterc has “Shree distinet purposes. First, it 
will provide responses to the research questions outlined in 
Gfiapter Iii. Next, it will develop and support conclusions 
from the research and application efforts related to this 
thesis. It will conclude by recommending future courses of 
action to pursue with the simulation effort. 

This chapter is written from a dual perspective: the 
managerial viewpoint and at the systems level. The concept 


iomio take the macro approach to the topics. 


B. RESEARCH QUESTION RESPONSES 

The research questions originally posed in chapter III, 
have provided a research oriented direction and emphasis for 
Mereh of the development and application effort. 
Additionally, they have a practical application to the 
Organizational management of AIS, microcomputers and 
simulation. 

1. The first research question was: 


Are microcomputers technically capable of executing 
software packages that simulate a major AIS? 


The author's response to this inquiry is yes. Rationale for 


this response is: 
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a. Many of the software packages used in microcomputers 
give the nardware a multiplier effect. Alea 
capability enables the hardware to handle tasks 
normally assumed to be performed by larger machines. 
Piomwmcesamp ley the dBASE Tl use of a relational 
database manager that performs functions with a 
Siete command Line that might take 50 lines of 


BASIC to perform i.e. a database sort. 


) 


b. The mono-user nature of most microcomputer systems 
allows them to concentrate their processing power on 
Tic wUEiMaimyeseask, ~limowis relative to the mainframe 
environment, where most AIS's exist, that supports 
multiple processing and multiple programming. The 
primary mission of the microcomputer is to run the 
SEmllati on. AS sien, it cam devote all of its 


mesOMmrces to accomplish’ the task without 
ist ract1on . 


c. Many of the AIS's were developed for mainframes with 
less processing power and less efficient software 
than are available on today's microcomputers. This 


ype of Situation favors the simulation of an AMS foal 
a Microcomputer, | 


2. The second research question asked: 


What are the positive and negative benefits associated 
with simulating a mainframe AIS on a microcomputer? 


To respond to this question, the thesis authors relied on 
their development experience, the experience of the users at 
the December,1983 MCPCC, their educational backgrounds, and 
their personal experiences in the military. 

a. The following positive benefits were identified: 

(1) The microcomputer presents a less costly 
environment in which to perform simulations, 
relative to mainframe and minicomputer 
alternatives. From a managerial perspective, 
this is the primary advantage of this approach 
Foust mulation, 

(2) Generally, microcomputers support simulation 


development better than mainframes and 
DaecConpwkers, “Lhts flows from the factethat 
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microcomputers are usually mono-user systems, 
and the developer does not have to compete for 
processing resources. Also, some of the 
development toels, such as text editors. on 
microcomputers are much easier to use than their 
mainframe counterparts. 


(3) Microcomputers, because of their widespread 


availability and their novelty value to certain 
peop te, eamend to encourage the use of 
Simulations. Also, portable microcomputers like 
Gee ha YP ROMMEL amidy@make the simulation 
transportable to the user. This removes the 
HatdreOuyethipmebo the terminal room or use of a 
modem required to execute a mainframe 
Sia el One siidsc ethecitt 1S sWAenNificant in a 
field training environment. 


b. The following disadvantages were identified: 


(1) A simulation is extremely sensitive to the 


(2) 


Simulation requirements and specifications 
Paase elise sensumeivatyotlows from the fact 
that the objectives and project plan are clearly 
developed in this phase. Any weakness in this 
process can have a ripple effect throughout the 
remainder of the simulation development 
Litecyc lex Himomme comes Critical cin the 
microcomputer arena, where there is a lack of 
sophisticated software requirements and 
development tools. While their mainframe 
relatives have techniques such as SREM and SADT, 
microcomputers still rely heavily on traditional 
development methods i. e. flowcharting. This 
can generate a pitfall as these techniques may 
be insufficient to handle the complexity 
Mmiplied in a simulation. As such, an inher emt 
disadvantage to simulations on microcomputers 
ex as is. It will likely be resolved, as the 
microcomputer applications software industry 
matures and moves farther into the market growth 
stage of the product lifecycle. 


a cinulatonmmwonmmammterocomputer is that it 
leaves a microcomputer in an organizational 
sre tata S . Cipaecimmelcnyece, with a little 
imagination, can think of many alternative uses 
Gements devices) thas Can inject change into an 
organization, which can generate both positive 
and negative effects. From a negative 
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PeTopective, it cam @@ause workers to pursue 
tasks other than their assigned positions i.e. 
Gevellopine applications, and it can violate 
Senporate 2niormation policy. These fLactors 
must be realized when considering implementing a 
microcomputer-based simulation, 


(3) The microcomputer simulation of a mainframe AIS 
implies that other computer resources exist in 
eieeo Fie alii zat 1.0 n., The presence of a 
microcomputer can create a redundancy of 
computing resources, and raises the question of 
iemecumveness sand efficiency of the other 
computing resources. Additionally, the problems 
of data compatability, telecommunications, and 
processor interface between the mainframe and 
Ene wmilecrocomputer can grow @meut of this 
Siewat lon, 


(4) A microcomputer simulation can generate all the 
organizational negative effects previously 
dise@ussed Wn chapter Il. 


Question 3, dealing with the specifics of simulation, 


asked: : 
What are the essential features that must be present 


in an ALS simulation to ensure it is a feasible and 
realistic model? 


Reviewing the development cycle and the user's feelings, the 


EeRests authors isolated the following features: 


a. 


The user interface must be very similar to the 
parent system. Defined in simple terms, the screen 
formats must be the same. This creates the initial 
ie cmmmterface With and perception of the 
Simulation. It is where the user relies on past 
knowledge of the parent system to operate the 
Simulation. Differences at this point would tend to 
discourage and confuse users. sgl aL See Si? foe 0) 18 
Heicemation and dissatisfaction normally results in 
lack of user acceptance of a system. Lack of user 
acceptance is the first step to system failure, as 
the system has failed to meet the needs of the 
audience it was designed to serve. 


Accuracy of simulation outputs and products is 
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weet al Pact moumaccUracy tends “fo hurt the 
simulation's credibility and causes users to revert 
®° eC€xXPerimenting with the parent systen. 
Meeeneucnavly, lack o£ aéctiracy can serve to form an 
Mimiinderraining base for simulation users to apply 
when operating the parent system. 


c. Simulation response time and turnaround must be 
equal to or better than the parent system. This 
feature exercises the simulation's time compression 
capability. Also, this time compression tends to 
better hold the user's interest and attention. 


ieomer support environment must be as transparent as 
possible to the user. This transparency decreases 
the complexity of the simulation from the user's 


perception. While increasing the ease of use, it 
mibeor serves to Minimize external distractions to the 
user, Cimcon toa tinemewacs a comcadiderataon, in &me 


ower ion of the KAYPRO’ 10 ever the KAYPRO TI, as 
the KAYPRO II would have required the user to handle 
floppy diskettes to initiate the simulation. 
The remaining spectrum of features and elements from the 
parent system can be abstracted, suppressed, or be subject 
PomimenormMation hiding in the simulation. Their explicit 
absence does not to detract from the feasibility and realism 
of the simulation. Also, specifying this realm of features 
as essential would tend to drive the simulation in the 
wimecrivon Of an emulation or replication. 
4. The next research question dealt with attempting to 
introduce objectivity into a subjective environment: 
How can an AIS simulation be designed to maximize user 
satisfaction within organizational and technological 
constraints? 7 
The first step in accomplishing this user satisfaction 


plumercrive is to get the users involved in the simulation 


development effort at an early stage. Since they will be 
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BHenwutletm@ate end user of the system, it is a naturai an 


Ci 


eee! Mecite20n to get them into the simulation develoument 
lifecycle. It also gives the users a vested interest in the 
ple@cess Of the simulation. After getting the users into the 
Process, it is desirable to define the measures of user 
satisfaction and the organizational and technological 
eomstraints. After they are defined, it is advisable to 
integrate them into a decision model. The software decision 
model and the hardware evaluation matrix outlined in 
Peevious chapters illustrate this type of integration. fhe 
Boe, oOt a tiodel tends to transform this subjective setting 
meeomammenj lective situation. Additionally, it provides an 
Opportunity to quantify the decision. While quantification 
-noreiniversally applicable, it provides the chance to 
Mmeeoentze different weighting factors for differing 
components. The prime example of decision model weakness is 
mien react ethat certain organizational constraints cannot be 
objectively modeled i.e. the ever present ‘seat of the 
pants’ estimate that comes from experience and good luck. 
5. The last research question was: 


Are microcomputer-based AIS simulations a viable 
Opememeronr future applications? 


Mtemanmemer to this query was a resounding YES. This 
positive reply was based on the following rationale: 
a. Current examples, such as the U. S. Marine Corps 


Standard Embarkation Management System (SEMS) 
Simulation and the MIS simulation described in 
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reference 10, have been extremely successful fron 
OrganizZational standpoint and the use 
He Ge pect iv é. The lessons learned in these two 
examples, coupled with the computer-based simulation 
learning curve effect, will tend to strengthen the 
effectiveness and efficiency of microcomputer-based 
Slmmeeations in the future. 


r-{ 
A 


[acm aaepant Crowe Of microcomputers, both tor 
Personal use and as decision aids, will tend to 
Zaascomimic spectrum or applications to expand to 
market needs. As has been discussed throughout this 
thesis, these market demands include simulations. 
This type of pent up demand is what first caused the 
Meenocomputer industry to blossom. It is entirely 
possible, and forseeable, that this process will be 


repeated with regard to microcomputer-based 
Surat Ons, 


Technology is diminishing the differential between 
the microcomputer and the mainframe. This trend 
will make the microcomputer of tomorrow as powerful 
as today's mainframe. This effect is visible today 
iimene form of the IBM X7T/370. Also, many of the 
ionmventionat stechnolopy MLcrocomputers on the 
Market today have substantially greater computer 
processing and memory power than yesterday's 
Mainframes. To wit, compare an 8088-based machine 
with expanded RAM (512 KB) to a IBM 650 or IBM 1401. 
These IBM products were considered to be the leading 
edge of mainframe technology in their time and have 
now been outprocessed by a desktop device. The 
effect*ef this change™@m hardware technology willwbe 
that less modification of parent systems will be 
required to create simulations. Less modification 
translates to lower cost and less development 
ic eer ewoe ciadinacterdatress that are routinely 
desirable in any new systems effort. 


The low cost of microcomputers can categorize them 
as a consumable in some circles. This low cost, 
coupled with their versatility in development On 
rapid prototypes, lends credence to the future of 
microcomputer-—based simulations. 
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ee CONCLUSIONS 

Ruemoumowimls  conelusions reflect the three central 
Memes 0: this thesis: AIS, microcomputers, and simulation. 
Further, these conclusions were drawn from the development 
team's efforts and experiences in the simulation development 


mirecycle. Mes On sttie Software and hardware selec tion=— 


acquisition-implementation-maintenance cycle advanced to the 


eome Llusions. 
ibe The first conclusion was: 


The simulation requirements and specifications phase 


is ine most important part of the simulation 
development lifecycle. 


This conclusion is based on the following: 


a. It reflects the philosophy 'If you don't know where 
youl re soing, you'll never get there.’ The 
Wehr ion of requirements and specifications 
integrates the system objectives into understandable 
software, hardware and system components. This type 
Omm@efanition 1s necessary to transform a concept 
mmigo ane actuality. 


b. The simulation requirements and specifications phase 
me CHticalemto delimiting the scope of the 
Simulation. This prevents the development of an 
emulation or a replication. 


c. The simulation requirements and specifications phase 
Meethe ftolmdation of the validation/verification 
cycle. This cycle is the internal review component 
Oimmthe simulation development lifecycle, and is 
intended to keep the other phases ‘honest’ with 
Hoeande to simmlation objectives. 


d. The simulation requirements and specifications phase 
is the basis of project management, as it defines 


Mmcm variables that must be controlled and 
coordinated. 
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om. 


The second conclusion emphasized project management: 


Communication, both verbal and written, is the most 
critical part of project management. 


This conclusion was driven by the following: 


Clive 


Communication is the fundamental link between the 
diverse interest groups of a project management 
Semortee AS SUeh, 12E serves to bind the effort into 


a unitied team if properly applied and effectively 
used, 


TOM temom is the medium that “tacilatates 
eMomasis and direction of project resources. AS a 
project management environment is frequently 
dynamic, communication also facilitates redirection 
and change of resource commitment. This makes 


communication a powerful and far reaching management 
tool. 


It should be noted that the absence of effective 
communication tends to generate the development of 
independent and individual projects. This is 


Soieranye Lo Lhe winder lying philosophy of project 
Management. 


Communication is the source of problem resolution 
when a conflict develops ina project team. This 
Peoltmem resolution, a decision that reflects 


compromise, must be communicated to ensure unity of 
goals. 


item next conelusion relates» to Microcomputers: 


itmmeesu@irstinet factors will affect and guide the 
Significance of microcomputers in organizations in the 
Hear term flture (5 -— 7 years): 


Pies eC@rrent lack of industry standards i.e. 
microprocessor, disk formats, communications 
protocol, and operating systems will change in 
response to market demands. 


The term microcomputer will gradually fade away in 


terms of current meaning, and will tend to evolve to 
denote a desktop mainframe by current standards. 
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=> Microcomputer applications software will catch and 
Surpass the current technology explosion in the 
Microcomputer hardware environment. 


These three factors are broad based and admply a far 
Peechtne Itmpact of microcomputers on organizations. As 
Buen. t&ney require further elaboration and support. 

Teme st actor, simpiying the fact that standards 
mimeecurtface in this rapidly expanding industry, will be the 
Zowveon Competition, market fallout, and compatability 
requirements for effective communication and information 
eemange. ane Umeslismauthors torecast thes following 
standards will appear in the industry: 


(1) The Primary Microprocessor: The Motorola 68000 
Sa com ee otahemtor Ends Projection is the 
size of the addressable memory afforded by this 
product, the processing speed, and the 68000's 
A eye tO oDrOovide timely execution of complex, 
layered software packages i.e. Apple's Lisa 
family and the MacIntosh. Also, the 68000 is 
powerful enough alone by itself to not require a 
separate, dedicated arithmetic coprocessor. A 
current market example of a 68000-based 
Prcwcommecr Is eeiemerinunichic LBMexT/370, 


GZ) The Primary Disk Format: The IBM 5 1/4" in the 
Sere rer tT mand ame ly 2° format in the long 
term. IBM will be the industry standard in the 
short term as a result of the market strength of 
IBM, the proliferation of IBM formatted software 
See ane scr OUte emonmonwtne LBM PC, and the 
abundance of IBM clones in the marketplace. The 
3.1/2" format will take charge in the long run. 
ieeigives the Usiermtme wtatity of ELitting in a 
shirt pocket. Also, it has a self protecting 
jacket that diminishes data integrity problems. 
Technology will solve the storage limitations of 
Bice disk. as certain 3 1/2" prototypes are 
eumrnentiy capable Giaholding 1.25 MB, 
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(3) 


The Standard Communications Protocol: This 
aueticeISmE OO OGyYtami1c to hazard an accurate 
Pact iO suits inpredictability is a fenction 
(meer eceonmrtedivecticure of ATGa. and tts 

of large scale IBM telecommunications efforts in 
the microcomputer realm. 


hoa eve 


(4) The Standard Operating System: UNIX. Strong 
indications are that a version of UNIX will be 
the primary market offering of IBM for the IBM 
ee Also, UNIX harmonizes well with the 
lige rola 6S000, ifeenas wae wedlth of supper t 
environments, is adaptable by diverse users, and 
has good telecommunications and networking 
capabilities. 

be DiUMmeGcineentimes SeGcomd factor, that today's 


meerocomputers will grow into desktop mainframes, are the 


mollowineg points: 


(1) 


(2) 


c. The 


This concept is a logical extension of the 
previously forecasted industry standards. 


As mentioned previously, new computer users are 
Gmeemesecek ine unavernsal solutions to all their 
Peowbmenc with a mecerocomputer. lo £ulfill this 
meant cimicstieameet demand, the vendorspewalil 
RFeopvouwd = OVeEplacamo increasingly powerful 
machines in the marketplace. 


fa Sto tint en rane et he comine of a4 


Meeerocaomputer software revolution, is supported by the 


BoOlvowinge explanations: 


(1) 


(2) 


The marketplace is demanding an ever increasing 
ise retriendlweamaneageriae decision aid.  IThis 
Muape lof (DhOductmasenommalily the result of 
software. Haimaware wiedekKomtime flexibility to 
respond to the multitude of situations that are 
implied by this type of decision aid. 


Surrently, TiMmome peRomdmlecet” lifecycle of 
Microcomputer applications software can be best 
estimated to be somewhere in the market growth 
stage. Ph ic eecteenote igs traditionally 
characterized by intense competition. In the 
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(3) 


IPeNcetEOnswisolLt ware arena, one has to oni, 
page through a single microcomputer periodical 
Commew- the aevertisements that attest to this 
MiPgeonse se OMpe ti. Elon . Thas COmMpeci: vO ly wal 
drive the research and development necessary to 
thrust microcomputer applications software into 
new technology spheres. Curmremety., Appice 
Computer has formulated their entire marketing 
effort around this strategy of stronger and far 
PoiGiine appl tcataons software. Their Lisa 
Series and the MacIntosh reflect this 
philosophy. 


Gurrventw Market. offerames in the area o£ 
integrated software packages mirror this 
technology boom. The idea of a menu driven 
package that includes word processing, DBMS, 
electronic spreadsheets, graphics and 
telecommunications is already a purchasable 
Dr odare t , ht retiects the users desires to 
explore a common organizational resource, 
information, by manipulating the data base into 
different views and perspectives. Examples of 
such integrated software products are Lotus 1]-2- 
3, Context MBA, and T/Maker III. 


d. There is an implied message in these three factors. 


The first part of this message is that many of the existing 


Pieimocom puters will continue to be used and will be 


categorized into generations as mainframes have been in the 


past. The generation demarcation will resemble this: 


(1) 


(2) 


(3) 


iteGenerationlmitce appre. tl Series, and the 
Apple DOS operating system. 


PiweGeneration eZ oummacroprocessor, coupled 
with the C/PM operating systen. 


3rd Generation: 8088 microprocessor, coupled 
with the MS DOS or C/PM 86 operating system. 


omnes pondingly, a new industry segment will develop to 


interface these older generations of technology with the 


forecasted industry standards. This is a simple matter of 
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lest Or y repeating itself, as has been evidenced by the Z-80C 
carads for the Apple II series, and the 8088 coprocessor for 
the Z-8G based systems. 

4. The last conclusion links simulations with the AIS 


environment: 


Simulations will develop a specialized niche in the 

AIS environment. They will evolve into a standard AIS 

Moguie, With daetraining function and responsibility. 
Mitemtact that training routinely spells the difference 


between user acceptance or rejection of an AIS drives this 
conclusion. A training package, embedded in a simulation 


iomemebe places this training resource internal to the AIS. 
It permits training, learning, and mistakes without 
impacting on the AIS outputs because of the simulation 
environment. Additionally, a simulation embedded in a AIS 
can be developed in a more expedient and cost effective 
manner by exploiting the concept of reusable code. Simply, 
the AIS can draw upon the existing AIS modules for logic and 
fommtain the results within the simulation. The MIS 
Simulation discussed in reference 10 is a current example 


Seerchis trend. 


D. RECOMMENDATIONS 
The outlined recommendations are divided into three 
Speec Pate paths: hardware, software, and 8S 7s tem 


recommendations. These recommendations are designed to 
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wees eSe ure Courses of action to pursue with the 
Simulation product cof this thesis. 
1. Hardware Recommendation 
This machine should have IBM compatability, to 
mmemude ROM and disk drive formats. Discussion of this 


recommendation includes: 


a. ft appears likely that many segments of the 
Govmenmniventeswatl  estandardize on the 8068 
HLeroprocessor, configured in the IBM PC format. 
This is conditional, if an organization as large 
as the federal government can ever standardize 
on anything as dynamic as microcomputers. The 
accompanying rationale is that if the government 
standardizes on this format the transformation 
of the simulation to this format would give it 
Emanasportabriity throuchout the federal 
Over Time nr. 


Vo Gack oOnrmiiwno ENe  Simubkation to a 32 bit 
architecture machine i.e. the Motorola 68000 is 
not considered viable. This reflects the fact 
that the government's computer procurement and 
acquisition procedures tend to lag behind the 
leading edge of technology. Further, there is 
Cteremniky NOtea woarce Quantity of general 
purpose software available for 32 bit 
architecture machines in the microcomputer 
Poot celtewot solLtkwanre could hamper the 
transformation process to a 32 bit architecture. 


PEPnecOSS, wit fo) Diteadrcechitecture, can address a 
larger RAM than can the current 8 bit Z-80. The 
potential of a larger RAM opens the door to the 
possisbility of a RAM disk. A RAM disk would 
diminish the need for a hard disk, as it would 
offer adequate file storage and faster access 
speed. 


d. If the current trend of decreasing hardware 
prices continues, it appears probable that an 
8088 based, IBM format microcomputer that meets 
the other hardware requirements will be 
available under the $3,000 cost ceiling. 
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2. Software Recommendation 
Convert the simulation to an integrated software 
package that employs a command language. This conclusion 
would give the development team all the power of dBASE II, 
fomemeereater flexibility. Additional discussion of this 
mecommendation include: 


a. An integrated software package would tend to 
Gxep re oO i tem the pow er o£ them hardware 
recommendation. This concept considers the 
addressability of the 8088, the clock speed of 
oer cOUGo, and the S088 craphics interface 
Gapapbrinty an an. lbM econitiguration. 


b. An integrated software package offers access to 
sraphics. This is a superlative teaching and 
Pea hie al dea ds tt ereinnorees the philosophy 
aioe pT crircmetce worth “a 1000) words. 
Additionally, integrated software packages tend 
HOO nen ns GRomcer a@ecitsion, tools than Can be 
found in dBASE II i.e. electronic spreadsheets. 


c. Integrated software packages offer enhanced 
features i.e. Monte Carlo simulation techniques. 
This type of power could propel the simulation 
Macon a wd sG be ten event. continuous f low 
simulation that would present students with 
constantly evolving decision problems. While 
such an environment is possible in dBASE II, it 
is usually not employed due to the development 
work involved in preparing the Monte Carlo 
Simulation module and the system state change 
module. 


3. System Recommendation 
Meomctorm the Simulation into a screen driven 
scenario that simulates the entire flow of the financial 
process. Discussion of this recommendation includes; 
a. This scenario would commence with a simulated 


purchase. Next, the documents for the purchase 
would appear on the screen. Then, the user 
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would move to the PEP simulation to enter the 
source documents into the system. This type of 
exrecnded "samuratiaon wouUuldee increase user 
Poeemtmance | OrmiEne Simulation, as it would 
parallel the actual operations of an accounting 
Or farce. Micwicoeettilation wowld stress the 
document flow into the system and then trace the 
document through the system to demonstrate how a 
Souree idioc im etwremcom: ribwtes Bec —fananc ia i 
information. 


Interface with a real time clock. This could be 
ieeueto drive a continuous Elow simulation, time 
Seat Pp —SimwUhationgmactivities, “and produce 
automatic date generation on simulation screen 
how mats. 
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APPENDIX A 


SOFTWARE DECISION MODEL 


ee I ty ne te WW WS IC 90 Oe oe ee KR KXKKEEKE 


GENERAL hep ee REQUIRENENTS * 


Wwe SM MMM MMMM M™M OEM ™ OM 


RODE BEY DBMS CMD SIMULATION 
LANGUAGE HOL LANGUAGE LANGUAGE 


DEVELOPMENT TIME 0 50 100 100 

TRANSPORTABLE 0 50 75 12) 

DOCUMENTATION 0 i> i a) 

EXPANSION 50 >) 100 100 

ME RACTIVE 100 100 100 100 

Pik RESPONSIVE 100 a0) 50 PS 

REALTIME SIMULATION 75 Zo es LS) 

NUMERIC ACCURACY 100 T> LCS, > 

SECURITY 100 50 iON) 75 

ADP ORIENTATION 0 Ue iD 50 

KRKMEK KKK KEK KKK KKK EK KKK KKK KKK EK KE KKK KKK KKK KEKE KK EK KE KK EK KK KKEK REESE 

* LANGUAGE SPECIFIC FACTORS/SOFTWARE ENGINEERING CONSIDERATIONS * 

KHKKKKK KE KKK KKK KKK KKK KK KEKE KE KK KKK KEKE KEKE KK KEK KE RHEE KEKE KEKE 
AS Sakis EY DBMS CMD SIMULATION 
LANGUAGE HOL LANGUAGE LANGUAGE 

STRUCTURED PROGRAMMING 0 tes 100 100 

MOBULARITY 0 WS 100 100 

INFO HIDING 0 100 100 100 
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ASSEMBLY 
LANGUAGE 


DESCRETE EXECUTION ) 
ORGANIC FUNCTIONS 0 
SYNTAX 0 
ERROR CHECKING 6) 
KREHKKREKEKKKKKKKKHKKKKKHKKKKKRKRKKRKHKRKKRKRKREKHY 
PDA DABASE / DATA STRUCTURE FACTORS * 
KHKKKKHKKKRKKHKKKRRKKKKRKRKRKRKRRKRKRKRRKRRKRKRKRENS 
ASSEMBLY 
LANGUAGE 
MULTIPLE DATA TYPES Wu's 
MENU ORLENTATION 25 
REAL TIME DB UPDATE 100 
LOGICAL VIEW OF DATA 25 
MEAN SOFTWARE 
REQUIREMENTSVALUE 33.33 
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DBMS CMD 


HOL LANGUAGE 

50 100 

100 168) 

50 50 

50 73 
DBMS CMD 


HOL LANGUAGE 


100 100 
Ue 100 
50 aS 
50 100 


G46 se) 3) 0 


SIMULATION 
LANGUAGE 


100 
100 
50 
TES, 


Ta eae! 


wie kB 


THE HARDWARE EVALUATION MATRIX 


HR EKKKKKKKK KEK RK KEKE KKK KE REREKKKEX 
* DBASE II MANDATORY REQUIREMENTS * 
HEKKEKKKKKKKKKHKKEKKEKEKKEKKKRRRRNKKEREK 

COMPAQ IBM PC IBM PCXT KAYPRO 2 KAYPRO1O EPSON QX 
RAM 96 96 96 64 64 64 
DISK 
Deve S D: ie Z 2 2 Z 
DISK 
CAPACITY 360 360 360 192 390 340 
KKK KKKK KKK KKH KKKEKEEE 
seOPERATEING SYSTEMS * 
KLEKSKEKKEKKKRKEKKEKKKEE 

COMPAQ IBM PC IBM PCXT KAYPRO 2 KAYPRO10 EPSON QX 
Cra 2.2 
eo BIT) ES ES Yes 
MS DOS 
@rG BIT) GES VES Yes 
KEK KKK KK KKK KKK KKK KE KKK KK KKK KKK KKKKKKKEKEKS 
Seve oe ECILEIED MANADATORY REQUIREMENTS * 
KMS KH KKK KHER KK EK KE KERR KKKK KEKE KKKKK AKERS 

COMPAQ IBM PC IBM PCXT KAYPRO 2 KAYPRO1O EPSON QX _ 

Sen EEN 
Syl ole 
80 X 24 ES ORS VES WES WES Yes 
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Sei LeMePC LEM PCAT KAYPRO 2° KAYPPOLOEPSON OX 


ex, 9" 
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HARDWARE 
Cosa 
< $3500.00 NO NO 
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2 


NO 


Lge 


S) 


9 2, i 
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DESIGNED AS 
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HARD DISK 
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HARD DISK 
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5 


yal 


=) 


50 


50 


US 


10 


30 
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SO a oi Pe ieee ekKAYPRO 22> KAYPROLO-EPSGN “Cx 


PRODUCT 
peru TATION 
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mao lHETIC 
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BOT AL 

Bio] EM 

RETAIL 
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HEN IE X 5 ISS ne, 21145 We WOOD ~ 3049 21443 


172 





Ab rk GC 
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APPENDIX D 
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APPENDIX E 


SUBSYSTEM AND PROGRAM MODULE DECOMPOSITION SUMMARY 


* MASTER CONTROL MODULE * 

% % 

KERKERREKEKKKKKKKKK KK KKK KKK KK KK KK KKK KKK RRKKRKREKS 

* BATCHDAT .CMD DELAY 2GMD ERRORCELRSEMDs 

* HEADER.CMD HEADER2.CMD INITMENU.CMD * 

ami VvEL1. CMD LOGOFF .CMD MAINPGM.CMD * 

* MTRANSEL.CMD PENDING.CMD Ee orn * 

* PEPMENU.CMD 5 oO (CMD SS, oLOGON. Ghp. = 

* + 

RERKRHKRHEKKKKKKKKKKKKKKKKKKKKKKKHKKKKKKKKKKKRKRKKES 
KKKKKKKKKEKKKKKEKKK SHER KKKKKKKKKKKKEKKKKKKKKKKKKKKKKREEN 
x % >> x 
* Ne UT “ * INQUIRY * 
* TRANSACTION * * TRANSACTION % 
. Blip o lo DEM . . SUBS io FEM i. 
KHKKKKKKKKKKHKKEKKS KEKKKKEKKKKKKKRKEKKHKKKKKKKKKKKEKRERKKEG 
% % % % 
* Holy, CMD * * BADGEINQ.CMD MJONINQ.CMD * 
* A2MIL.CMD * * BCATINQ.CMD PAYINQ.CMD * 
* AD.CMD * * CACINQ.CMD PHF INQ.CMD * 
* AL .CMD * * Sl OE FEIN) OB, RCATINQ.CMD * 
* AOCIV1I.CMD * * CMONINQ.CMD REIMBINQ.CMD * 
* AOMIL.CMD * * DAYSINQ.CMD RONINQ.CMD * 
* Bue Cid * * DOCINQ.CMD SSNINQ.CMD * 
* Gee tuRe. CMD * * EEINQ.CMD IPE DEN O28 60, * 
* CATCHEM.CMD * % EXPINQ.CMD UFO .CMD * 
* Cou bad “CMD * % FAINQ.CMD WCINQ.CMD * 
* DiS CMD * * GRADEINQ.CMD NAMEINQ.CMD * 
* 0S. CMD * * Moen re Mil GbE oO, CMD * 
* LETGO .CMD * * n 
* Ren be CMD * * a 
* % % * 
KEKKHKEHKKKKKHKKEX KEKE KKKKKEKHEKKKKHKKKKKKKKKKKKKKEKRKEKSE 
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APPENDIX F 


PEP MICROCOMPUTER SIMULATION USER GROUP SURVEY 


KEKKKKKKRKK KK KK KRKKKEKKEEE 


PRIME ENHANCEMENT PROJECT MICROCOMPUTER SIMULATION oo 


%K OK OK I 2K 


USER GROUP SURVEY es 


LHRH 


The following questions are intended solely as a 
feedback device for you, the users of the MCPCC 


Microcomputers, to the Project Team. Your responses will 
serve to guide the development and implementation of the 
system. All information you place herein will remain 


Bemeerkly confidential. 
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Wey Flease circle your age group: 
ees eb. 26 —- 30 CC. 31 = 35 D. 36 = 40 E. 40 - + 
2.) Please write your billet title and type of command: 
Mts peor Command: FMF, Base, Station, MCDEC, HOMC, 
Others) 


Dieeret LTitie: 


Type of Command: 





3.) Have you ever used a personal computer: 

At home VOEES) NO 

Ae wor k ness NO 
feomeein  tresponse to the following questions, circle the 


number that best indicates your feelings toward the 
statement. The numbers correspond to the following: 


1 2 3 4 5 
Strongly Somewhat No Somewhat Sr omwe. 
Disagree Disagree Opinion Agree Agree 


A. The tutorial was easy to use 
and understand. 1 2 5 4 5 


B. The tutorial provided adequate 
Suidance to allow me to enter 
iiiommatron to PEP, 1 2 S) 4 5 


C. The tutorial was too long. lk Z 3 4 > 


NTE 





D. I was able to read the computer 


penecen Without any trouble, i 2 3 a 5 
E. The screen prompts for PEP 

were easy to follow. 1 2 3 4 S) 
F. I was able to follow what 

was happening on the screen 

PaOiwtne tutorial. it Z 3 4 5 
G. I learned something positive 

about personal computers from 

Pie OC . i 2 S 4 5 
H. I would consider getting a 

personal computer for my work 

environment based upon the PCC, 1 z. 5 4 5 
I. I was able to understand the 

value of electronic spread- 

sheets based upon the PCC. 1 2 S 4 5 
J. Iwas able to understand what 

Moeumeamedo fOr My Unit from 

Ene. Uc 3 l As 3 4 5 
=) Please provide any further suggestions for 


improvement/constructuve criticism of the project that you 
might have. 


lee 





APPENDIX G 


ANSIVolowor MerPCC SURVEY 


fee «6 AMPLE DATA 
Number of Possible Responses: 20 
Number of Actual Responses: 20 
Response Rate: 100% 
pumvey Date: 8 December, 1983 
Number of Questions: 16 


bee SURVEY RESPONSE DATA 


ieee Please circle your age group: 


pwmeoe= 25 BS, 26>— 305°C, 31 = 35 D, 36 —- 40 E. 40 - + 


# OF 
PeoPONSES 3 7 4 4 2 
ie 10N3 
SAMPLE 15 S)s 20 20 10 


2A ) Please write your billet title and type of command: 
(type of command: FMF, Base, Station, MCDEC, HQMC, 
Others) 
Billet: All responses were varied, with no commonality. 


Type of Command: 


FMF BASE STATION MCDEC HQMC OTHER 
# OF 
MeorONSES 3 Z 4 i! i f) 
h OF 
SAMPLE lee 10 20 > 33) 9) 


ES, 





fan) gee ae . 3 =~ . 2 
3.) ave you ever used a personal computer: 


Ae fee mene VES NO 
¢ OF 
RESPONSES 6 es 
EeOr 
SAMPLE 30 70 
Eeeeneewor Kk ES NO 
% OF 
RESPONSES 13 v 
% OF 
SAMPLE 65 255 


memeein response to the following questions, circle the 
number that best indicates your feelings toward the 
statement. 


A. The tutorial was easy to use and understand. 


l Z 3 4 5 
Semone ly Somewhat No Somewhat Strongly 
Disagree Disagree Opinion Agree Agree 
# OF | 
ier ONSES O 0 0 8 liney 
% OF 
oP LE O 0 O 40 6 0 


Mean Response Value for Question 4A: 4.6. 


180 





B. The tutorial provided adequate guidance to allow me to 


em@rereantormation to PEP. 


: 2 3 4 
Strongly Somewhat No Somewhat 
Disagree Disagree Opinion Agree 
r OF 
RESPONSES QO 0 2 3 
hm OF 
sa MiPLE OQ 0 10 1S 


Mean Response Value for Question 4B: 4.65. 


See ote tutorial was too long. 


] Z 3 4, 
Strongly Somewhat No Somewhat 
Disagree Disagree Opinion Agree 
a Oa 
REOEONSES 3 4 6 i 
bh OF 
DAM PLE iS 20 50 a5 


Mean Response Value for Question 4C: 2.85. 


oe) 


Strongly 
Agree 


1 


ri) 


5) 


Strongly 
Agree 


Di I was able to read the computer screen without any 


trouble. 
Z 3 4 
prrong 1 y Somewhat No Somewhat 
Disagree Disagree Opinion Agree 
wor 
hEOFONSES Q Q OQ 9 
D. OF 
SAMPLE OQ QO 0 45 


Mean Response Value for Question 4D: 4.55. 


To 


5 
Stroma, 
Agree 
11 


ae 





E. The screen prompts for PEP were easy to follow. 


] 2 3 4 5 
Strongly Somewhat No Somewhat Ser Omen, 
Disagree Disagree Opinion Agree Agree 
RESPONSES 0 i 0 Jedi 8 
hm OF 
SAMPLE 0 S 0 DS) 40 


Mean Response Value for Question 4E: 4.30. 


F. Iwas able to follow what was happening on the screen 
meom the tutorial. 


H Z 3 d, 5 
Serone ly Somewhat No Somewhat Strone ly 
Disagree Disagree Opinion Agree Agree 
me 
heorONSES O li 0 10 9 
* OF 
SAMPLE 0 5 0 50 45 


Mean Response Value for Question 4F: 4.35. 


G. I learned something positive about personal computers 
mom the PCC. 


l 2 3 d, 5 
per one ly Somewhat No Somewhat Strongly 
Disagree Disagree Opinion Agree Agree 
poe 
RESPONSES l l it 9 8 
% OF 
sam PLE 5 3) 3) a5 40 


Mean Response Value for Question 4G: Dede 


lte\ 74 





fi. I would consider getting a personal computer for my work 
Emr ironment based upon the PCC. 


HV 2 3 4 5 
strongly Somewhat No Somewhat Sirona ly 
Disagree Disagree Opinion Agree Agree 
7 OF 
RESPONSES 1 3 5 3 8 
ee OF 
SAMPLE D i= 7 1a, 40 


Mean Response Value for Question 4H: 3.7. 


ie. iMeveacumaDile fo und@erstand the value of electronic 
spreadsheets based upon the PCC. 


err Z 3 4 5 
Serong ly Somewhat No Somewhat Stronc., 
Disagree Disagree Opinion Agree Agree 
# OF 
RESPONSES Q 2 7 9 2 
h OF 
San PLE Q 10 a5 45 10 


Mean Response Value for Question 41: 3.55. 


Je I was able to understand what PEP can do for my unit 
meom the PCC. 


i Z 3 4 5 
strongly Somewhat No Somewhat Serong ly 
Disagree Disagree Opinion Agree Agree 
nm OF 
RESPONSES Q Z 7 9 2 
» OF 
SAMPLE Q 10 35 45 10 


Mean Response Value for Question 4J: 3.55. 


tos 





rc, 


ee, 


Jae 
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